What does client-side encrypted PDF sharing actually mean?

It means the server storing your shared file literally cannot decrypt it. The encryption key is generated in the sender's browser, never uploaded, and only the recipient's browser can reconstruct it — either from the URL fragment or from a passphrase the sender shares out-of-band. The server only ever holds ciphertext.

What encryption does PDF Pro use for client-side encrypted sharing?

AES-256-GCM symmetric encryption with a 96-bit random initialization vector per file. For passphrase mode, keys are derived via PBKDF2-SHA256 with 310,000 iterations over a 128-bit random salt.

What is the difference between fragment mode and passphrase mode?

Fragment mode puts the 256-bit key in the URL hash (after #), which browsers never send to the server. Anyone with the full link can decrypt. Passphrase mode derives the key from a passphrase the sender picks — the ciphertext stays unreadable without it. Passphrase mode is safer if the link leaks; fragment mode is easier for low-friction sharing.

Is a URL fragment really safe as an encryption key carrier?

Compliant browsers never transmit the fragment portion of a URL (after #) to the server. It stays client-side. That's what makes the share link itself the decryption credential — the key rides with the recipient, not with the upload.

Can PDF Pro or a court read files stored via client-side encrypted sharing?

No. The server stores AES-256-GCM ciphertext plus an initialization vector (plus a salt in passphrase mode). Without the key — which we never received — that data is cryptographically indistinguishable from random bytes. We can only disclose ciphertext, which is what we have.

What happens if I lose the link or forget the passphrase?

The file is permanently unrecoverable. This is by design — client-side encryption means no recovery path, because a recovery path would require us to hold the key.

Is client-side encrypted PDF sharing free?

Yes. The free tier supports AES-256-GCM encryption and 24-hour link expiry with no signup required. The free-tier file cap is approximately 25 MB per transfer; Pro extends the expiry window and raises file limits.

Does the recipient need an account?

No. The recipient clicks the link, their browser decrypts locally via the Web Crypto API, and they download the file — no signup, no install.

Clientseitig verschlüsselt · PDF-Sharing

Clientseitig verschlüsseltes PDF-Sharing, richtig erklärt.

„Ende-zu-Ende verschlüsselt" wird lose verwendet. Hier ist der tatsächliche kryptografische Mechanismus hinter einem clientseitig verschlüsselten PDF-Link — AES-256-GCM, Schlüsselverwaltung, Fragment- vs. Passphrase-Modus und was der Server buchstäblich nicht tun kann. Hinweis: „Zero-Knowledge" bezieht sich auf dieser Seite darauf, dass der Server keine Informationen besitzt, die Ihre Datei entschlüsseln könnten, nicht auf formale Zero-Knowledge-Beweise (ZKPs) — das Produkt verwendet keine ZKPs.

lockAES-256-GCM vpn_keyPBKDF2-SHA256 · 310,000 linkFragment oder Passphrase memoryWeb Crypto API

sendVerschlüsselten Link senden So funktioniert's

Was „Zero-Knowledge" hier bedeutet

Eine kurze Klarstellung vorab: Dieses System verwendet keine Zero-Knowledge-Beweise (ZKPs). Der Begriff „Zero-Knowledge" bezieht sich auf dieser Seite auf die schwächere, aber praktisch nützliche Eigenschaft, dass der Server, der Ihre geteilte Datei speichert, kein Wissen — weder kryptografisch noch operativ — besitzt, mit dem sie entschlüsselt werden könnte. Der Schlüssel berührt den Server nie, daher kann der Server ihn unter keinen Umständen preisgeben. Der Mechanismus ist schlichte clientseitige Verschlüsselung plus ein Schlüssel, der nur im URL-Fragment reist (oder aus einer Passphrase abgeleitet wird, die der Server nie sieht).

memory

Die Verschlüsselung erfolgt in Ihrem Browser

Nicht auf dem Server, nicht in einem Worker, den Sie nicht kontrollieren — in Ihrem Tab, über window.crypto.subtle. In den DevTools verifizierbar.

cloud_off

Nur Chiffretext wird hochgeladen

Der Upload-Body ist AES-256-GCM-Chiffretext. Die PDF-Datei, der Dateiname und die Metadaten erreichen den Server nie in lesbarer Form.

vpn_key

Der Schlüssel reist mit dem Empfänger

Entweder im URL-Fragment (das nie an Server gesendet wird) oder abgeleitet aus einer vom Absender gewählten Passphrase. So oder so sehen wir ihn nie.

block

Keine Wiederherstellung = keine Hintertür

Link verloren oder Passphrase vergessen? Die Datei ist endgültig weg. Da der Schlüssel unseren Server nie erreicht, gibt es keinen Wiederherstellungsweg, der die Garantie schwächen würde.

Wie ein clientseitig verschlüsselter PDF-Link aufgebaut ist

Eine Schritt-für-Schritt-Erklärung dessen, was der Browser des Absenders, der Server und der Browser des Empfängers jeweils tun — mit den tatsächlichen Web-Crypto-Aufrufen.

1 — Browser des Absenders

// 256-bit AES key, generated locally key = crypto.subtle.generateKey({name:"AES-GCM", length:256}) // fresh 96-bit IV per file iv = crypto.getRandomValues(new Uint8Array(12)) // encrypt locally; GCM gives us an auth tag for integrity ct = crypto.subtle.encrypt({name:"AES-GCM", iv}, key, pdfBytes) // upload ciphertext + iv (and salt, if passphrase mode) id = await PUT("/api/transfer", ct, {iv, expiry})

2 — Form des Teilen-Links

// fragment mode: key lives after # link_f = `https://pdfpro.tools/s/<ID>#<KEY>` // passphrase mode: no key in the link; recipient must know the passphrase link_p = `https://pdfpro.tools/s/<ID>`

3 — Server speichert undurchsichtige Bytes

ciphertext = ??? // random-looking, unreadable iv = 12-byte nonce salt = 16-byte random (passphrase mode only) expiry = 24h free / 30d Pro

4 — Browser des Empfängers

// browsers never transmit the URL fragment to the server rawKey = /* from location.hash OR */ PBKDF2(passphrase, salt, 310_000, "SHA-256") ct = await GET("/api/transfer/" + id) pdf = crypto.subtle.decrypt({name:"AES-GCM", iv}, importKey(rawKey), ct) // browser serves pdf to Downloads

Fragment-Modus vs. Passphrase-Modus

Zwei Wege, den Schlüssel zum Empfänger zu transportieren. Dieselbe Chiffretext-Garantie, unterschiedliche Kompromisse bei Benutzbarkeit und Leckagerisiko.

Fragment-Modus

Der Schlüssel reist im URL-Hash (`#`)

Der einfachste Ablauf: Link kopieren, in einen Chat an den Empfänger einfügen, fertig. Der Teil der URL nach # wird von keinem konformen Browser an einen Webserver gesendet — das hält den Schlüssel privat.

Ein Schritt für den Empfänger — den Link anklicken.
Geringe Reibung, geeignet für Sharing mit niedriger bis mittlerer Sensibilität.
Risiko: Leckt der Link in einem Screenshot oder über Browser-Sync, leckt die Datei mit.
Verwenden Sie ihn, wenn Sie dem Kanal vertrauen (signierter Messenger, interner Chat).

Passphrase-Modus

Schlüssel aus einer Passphrase abgeleitet (PBKDF2)

Der Absender wählt eine Passphrase. Der Browser leitet einen 256-Bit-Schlüssel über PBKDF2-SHA256 mit 310.000 Iterationen über einen zufälligen 128-Bit-Salt ab. Der Salt wird serverseitig gespeichert; die Passphrase wird out-of-band geteilt (Telefon, Signal, persönlich).

Zwei-Faktor-Sharing: Link und Passphrase reisen getrennt.
Der Link allein reicht nicht — der Chiffretext bleibt unlesbar.
Passphrase-Stärke zählt: 310k Iterationen verlangsamen Brute-Force, retten aber keine 6-Zeichen-Passphrase.
Verwenden Sie ihn, wenn der Link weitergeleitet oder an einem Ort gespeichert werden könnte, dem Sie nicht voll vertrauen.

Eigenschaft	Fragment-Modus	Passphrase-Modus
Schlüsselträger	URL-Hash (`#`)	Passphrase + Salt
Sieht der Server jemals den Schlüssel	Nein	Nein
Server speichert	Chiffretext + IV	Chiffretext + IV + Salt
Aufwand für den Empfänger	Link anklicken	Link anklicken + Passphrase eingeben
Leckbar per Screenshot	Ja (Link = Schlüssel)	Nein (Link allein nutzlos)
Brute-Force-resistent	256-Bit zufällig	Hängt von der Passphrase ab
Am besten für	Sharing mit geringer Reibung über vertrauenswürdige Kanäle	Sharing mit höherer Sensibilität

Warum ein serverseitig gespeicherter Chiffretext Sie dennoch schützt

Man fragt oft: „Wenn er auf eurem Server liegt, wie ist er dann privat?" Die Antwort lautet, dass Chiffretext nicht die Datei ist. Ohne den Schlüssel sind es nur zufällig aussehende Bytes. Was das in der Praxis bedeutet:

storage

Datenbankeinbruch = Chiffretext-Leck

Würde ein Angreifer unsere Datenbank kompromittieren, ginge er mit undurchsichtigen Bytes weg. Die Wiederherstellung einer einzigen Datei würde das Brute-Forcen eines 256-Bit-Schlüssels erfordern — mit bekannter Physik nicht machbar.

gavel

Vorladung liefert Chiffretext

Ein Gericht kann uns zwingen, herauszugeben, was wir haben. Was wir haben, ist Chiffretext. Eine Gerichtsanordnung kann rückwirkend keinen Schlüssel erzeugen, den wir nie gespeichert haben.

group

Insider-Zugriff wird neutralisiert

Ein böswilliger Mitarbeiter mit vollen Datenbank-Zugangsdaten kann die Dateien dennoch nicht lesen. Die Garantie wird durch Mathematik durchgesetzt, nicht durch Zugriffskontrolle.

timer

Ablauf verstärkt die Garantie

Chiffretext wird beim Ablauf gelöscht (24 h kostenlos, bis zu 30 d Pro). Danach ist sogar der Chiffretext weg — die einzige Kopie der Datei existiert dort, wo sie entschlüsselt wurde.

warningEhrliche Einschränkungen

Clientseitige Verschlüsselung löst keine Endpunktsicherheit. Schadsoftware auf dem Gerät des Absenders oder Empfängers kann den Schlüssel aus dem Speicher stehlen. Eine kompromittierte Browsererweiterung kann die entschlüsselte Datei lesen. Und ein weitergeleiteter Link in einem Gruppenchat hebt jede kryptografische Garantie auf. Die Architektur erhöht die Kosten eines Einbruchs; sie eliminiert nicht jedes Risiko.

Clientseitige Verschlüsselung vs. andere „sichere" Optionen

Ein klarer Vergleich gängiger Optionen zum Teilen einer PDF. Die meisten als „sicher" bezeichneten Optionen sind transportverschlüsselt — sie schützen die Daten während der Übertragung, aber der empfangende Server hält weiterhin Klartext und Schlüssel.

Option	TLS bei der Übertragung	Server kann die Datei lesen	Ablauf	Empfängerkonto
E-Mail-Anhang	Meistens ja	Ja — bei jedem Hop	Für immer	Nicht erforderlich
Allgemeiner Cloud-Sharing-Link	Ja	Ja	Optional	Manchmal
Passwortgeschützte PDF	Ja	Ja (wenn der Host die Datei hat)	Niemals	Nicht erforderlich
PDF Pro (Fragment-Modus)	Ja	Nein	24 h / 30 d	Nicht erforderlich
PDF Pro (Passphrase-Modus)	Ja	Nein	24 h / 30 d	Nicht erforderlich

Weiterführende Lektüre

Vertrauensabhängiges Sharing vs. Zero-Knowledge Live-Rennen

Dasselbe Ziel — eine PDF teilen. Sehen Sie zu, wie die beiden Vertrauensmodelle Seite an Seite ins Ziel kommen.

cloud_upload

Vertrauensabhängige Freigabe

Server hält Klartext

PDF zum Server hochladen
Server hält KlartextKlartext
Server verspricht zu löschenVertrauen
Einbruchsrisiko auf deren SeiteRisiko
Empfänger lädt Klartext herunterOffengelegt

Klartext-Kopien auf dem Server

Server kann lesen

Schlüssel auf dem Server

shield_lock

Dieses Tool

Zero-Knowledge-Freigabe

PDF im Browser verschlüsselnE2E
Server hält nur ChiffretextZero-Knowledge
Empfänger entschlüsselt lokalFertig

check_circle

Bereits geteilt — und der Server kann es nicht lesen.

Kein Klartext auf dem Server. Keine Schlüsselverwahrung. Einbruchssicher by Design.

Klartext-Kopien auf dem Server

Server kann lesen

Nein

Schlüssel auf dem Server

Nein

Die Animation läuft einmal pro Ansicht — tippen Sie auf Wiederholen, um sie erneut zu sehen.

Häufig gestellte Fragen

Was bedeutet clientseitig verschlüsseltes PDF-Sharing wirklich?

Es bedeutet, dass der Server, der Ihre geteilte Datei speichert, sie buchstäblich nicht entschlüsseln kann. Der Verschlüsselungsschlüssel wird im Browser des Absenders erzeugt, nie hochgeladen, und nur der Browser des Empfängers kann ihn rekonstruieren — entweder aus dem URL-Fragment oder aus einer Passphrase, die der Absender out-of-band teilt. Die Garantie wird durch Kryptografie durchgesetzt, nicht durch eine Zugriffskontrollrichtlinie, die wir ändern könnten. Hinweis: Dies unterscheidet sich von formalen Zero-Knowledge-Beweisen (ZKPs), die dieses Produkt nicht verwendet.

Welche Verschlüsselung verwendet PDF Pro für clientseitig verschlüsseltes Sharing?

AES-256-GCM symmetrische Verschlüsselung mit einem 96-Bit-zufälligen Initialisierungsvektor pro Datei. Im Passphrase-Modus werden Schlüssel über PBKDF2-SHA256 mit 310.000 Iterationen über einen 128-Bit-zufälligen Salt abgeleitet. Die gesamte Kryptografie läuft in der nativen Web-Crypto-API des Browsers.

Was ist der Unterschied zwischen Fragment-Modus und Passphrase-Modus?

Der Fragment-Modus platziert den 256-Bit-Schlüssel im URL-Hash (nach #), den Browser niemals an einen Server senden. Wer den vollständigen Link hat, kann entschlüsseln. Der Passphrase-Modus leitet den Schlüssel aus einer vom Absender gewählten Passphrase ab; ohne sie bleibt der Chiffretext unlesbar. Der Passphrase-Modus ist sicherer, falls der Link leckt; der Fragment-Modus ist einfacher für reibungsarmes Sharing. Siehe die Vergleichstabelle oben.

Ist ein URL-Fragment wirklich sicher als Träger eines Verschlüsselungsschlüssels?

Konforme Browser übertragen den Fragment-Teil einer URL (den Teil nach #) nie an den Server. Er bleibt clientseitig und ist nur für JavaScript sichtbar, das im Tab des Empfängers läuft. Das macht den Teilen-Link selbst zum Entschlüsselungs-Credential — der Schlüssel reist mit dem Empfänger, nicht mit dem Upload. Sie können das im Netzwerk-Tab Ihres Browsers überprüfen: Die Anforderungs-URL wird am ? oder # abgeschnitten.

Können PDF Pro oder ein Gericht über clientseitig verschlüsseltes Sharing gespeicherte Dateien lesen?

Nein. Der Server speichert AES-256-GCM-Chiffretext plus einen Initialisierungsvektor (plus einen Salt im Passphrase-Modus). Ohne den Schlüssel — den wir nie empfangen haben — sind diese Daten kryptografisch nicht von zufälligen Bytes zu unterscheiden. Wir können nur Chiffretext herausgeben, was wir haben.

Was passiert, wenn ich den Link verliere oder die Passphrase vergesse?

Die Datei ist dauerhaft nicht wiederherstellbar. Das ist beabsichtigt — clientseitige Verschlüsselung bedeutet keinen Wiederherstellungsweg, denn ein solcher Weg würde erfordern, dass wir den Schlüssel halten. Speichern Sie die Passphrase in einem Passwortmanager und bewahren Sie den Link an einem dauerhaften Ort auf.

Ist clientseitig verschlüsseltes PDF-Sharing kostenlos?

Ja. Die kostenlose Stufe unterstützt AES-256-GCM-Verschlüsselung und 24-Stunden-Link-Ablauf ohne Registrierung. Das Datei-Limit der kostenlosen Stufe liegt bei etwa 25 MB pro Übertragung; Pro verlängert das Ablauffenster auf 30 Tage und hebt die Dateigrößenbeschränkungen an.

Benötigt der Empfänger ein Konto?

Nein. Der Empfänger klickt auf den Link, sein Browser entschlüsselt lokal über die Web-Crypto-API und er lädt die Datei herunter — keine Registrierung, keine Installation, keine Portal-Wand zwischen ihm und der Datei.

Senden Sie einen Ende-zu-Ende verschlüsselten Link. Lassen Sie ihn planmäßig ablaufen.

AES-256-GCM-Verschlüsselung in Ihrem Browser. Keine Registrierung, kein serverseitiger Klartext, keine Wiederherstellungs-Hintertür.

sendVerschlüsselten Link erstellen