Secure Transfer · End-to-End Encrypted
Secure PDF Transfer Our Server Can't Read.
Your file is encrypted in your browser before it leaves. The share link expires, the ciphertext deletes itself, and PDF Pro's server literally cannot open what it stores — because we never receive the key.
Secure PDF transfer by design: encryption runs client-side with AES-256-GCM, the decryption key stays with you, and PDF Pro's server only ever handles ciphertext — end-to-end encrypted PDF sharing without enterprise account walls.
lockAES-256 in your browser
vpn_key_offServer stores ciphertext only
scheduleLinks expire in 24 h–30 d
In deinem Browser verschlüsselt, unreadable on our server
Secure Transfer is the one flow in PDF Pro where end-to-end encryption here is a design property, not a marketing phrase. The server stores ciphertext it cannot decrypt.
Two key modes
Fragment mode: the key rides in the URL hash, which browsers never transmit to servers. Passphrase mode: the key is derived from a passphrase you share out-of-band; only the salt is stored.
AES-256-GCM, client-side
Encryption and decryption happen in the browser using the Web Crypto API. PDF Pro's infrastructure never holds plaintext or the key.
Expiring links
Free tier links expire after 24 hours; Pro links up to 30 days. Expired ciphertext is deleted and cannot be recovered.
Kein Konto to receive
Recipients open the link and decrypt in their browser. No signup wall between the sender's encryption and the recipient's download.
Why PDF Pro instead of other tools
The differences that matter for secure PDF transfer — all real, not marketing.
End-to-end encryption by architecture, not policy
The decryption key never reaches our server (fragment mode) or is derived from a passphrase we never receive (PBKDF2 mode). We cannot open files we store.
In deinem Browser verschlüsselt, not on our server
AES-256-GCM runs client-side before upload. Tools like WeTransfer encrypt only at rest, where they still hold the key.
Expiring links by default
Ciphertext is deleted automatically (24 h free, 30 d Pro) — not left in a shared folder indefinitely.
No recipient account needed
Whoever gets the link decrypts in their browser. No signup wall between sender and recipient.
How end-to-end encryption works
A three-step cryptographic handoff where PDF Pro's server handles ciphertext only.
1
Key generation
Your browser generates a random AES-256-GCM key (fragment mode) or derives one from your passphrase via PBKDF2-SHA256 with 310,000 iterations (passphrase mode).
2
Local encryption
The file is encrypted in your browser and the ciphertext is uploaded. Fragment mode: the key is appended to the link after the "#" — browsers keep this client-side. Passphrase mode: only the salt is stored on our server.
3
Recipient decrypts
The recipient opens the link; their browser reads the key from the URL fragment or asks for the passphrase, downloads the ciphertext, and decrypts in the tab.
Anwendungsfälle
When "encrypted attachment" is not a good enough answer.
Signed contracts to clients
Share via expiring link instead of an email attachment that sits forever in their inbox and intermediate mail servers.
Financial documents to advisors
Accountants, tax advisors, and auditors who need statements without the ciphertext persisting on shared mail infrastructure. Before sharing, you may want to convert your PDF to Word for markup or convert your PDF to Excel for analysis.
Medical documents, one-time
Send to a specialist without creating portal accounts. Flag single-use so the ciphertext deletes after the first decryption.
Security boundary (read this)
- Anyone with the full link can decrypt in fragment mode. Treat the link like the file itself.
- For higher assurance use passphrase mode and send the passphrase through a separate channel (phone, Signal, in-person).
- Links expire and the ciphertext is deleted. Expired files cannot be recovered — not by you, not by us.
- PDF Pro stores ciphertext it cannot decrypt. Even with full database access, the server cannot read your file.
Honest limitations
- Lost link (fragment) or forgotten passphrase (PBKDF2) = permanently unrecoverable. This is a direct consequence of end-to-end encryption, not a bug — there is no "forgot password" flow.
- File size cap: approximately 25 MB per transfer on the free tier.
- Secure Transfer is not a DLP replacement for a regulated enterprise environment — no server-side logging, access policies, or audit trail we can promise.
Verwandte Tools
Email-attached PDF vs E2E encrypted transfer live race
Same goal — send a PDF securely. Watch the two paths finish, side by side.
Plain email attachment
Gmail / Outlook / Exchange
- Attach PDF to email
- Your mail server stores itIndexed
- Recipient server stores itIndexed
- Backups retain copiesBacked up
- Plaintext at 4+ locationsExposed
Plaintext copies
4+
Encryption layer
TLS only
Key control
Server
This tool
End-to-end encrypted transfer
- Encrypt PDF in browserE2E
- Only ciphertext on relayZero-knowledge
- Recipient decrypts locallyFertig
check_circle
Already delivered — sealed end-to-end.
No plaintext on mail servers. No retained backups. Keys never leave the sender.
Plaintext copies
0
Encryption layer
E2E
Key control
Sender
Animation läuft einmal pro Aufruf — auf Wiederholung tippen, um sie erneut zu sehen.
Häufig gestellte Fragen
Is my PDF actually end-to-end encrypted?
Yes. Encryption happens in your browser before upload; decryption happens in the recipient's browser. Our server handles ciphertext only.
How long does a secure PDF link last?
Free tier: 24 hours. Pro: up to 30 days. Expired links return not-found and the underlying ciphertext is deleted.
Can I password-protect the link or limit downloads?
Yes. Passphrase mode adds a second factor separate from the link. You can also set a single-use flag so the ciphertext is deleted immediately after the first successful decryption.
What happens if I lose the link or forget the passphrase?
The file is permanently unrecoverable. Because the key never reaches our server, PDF Pro genuinely cannot decrypt it — there is no override, no recovery, no support ticket that can fix it.
Can PDF Pro read the file I'm sending?
No. The server stores ciphertext and either the IV (fragment mode) or IV plus salt (passphrase mode). None of that is enough to decrypt without the key, which we never receive. To guarantee the recipient can verify integrity, pair the transfer with a signature — see our cryptographic signing overview.
Is this really safer than sending by email?
For untrusted email paths, yes — email attachments are typically unencrypted at rest on intermediate servers and may be retained for years. Secure Transfer ciphertext has an expiry date and our server cannot read it. That said, "safer" is about threat model — if a recipient forwards the decrypted file to someone untrusted, no transport-layer security helps. For the practical workflow, see how to send a PDF securely with an encrypted link.
What does end-to-end encrypted PDF transfer actually mean?
It means PDF Pro's server never has the information needed to decrypt your file. In fragment mode the key lives in the URL hash — a part of the link browsers never send to servers. In passphrase mode the key is derived from a secret you share separately. In both cases the server stores ciphertext plus an IV, and that's mathematically not enough to read the file. For a deeper technical breakdown, see our encrypted file transfer whitepaper.
Can I share large PDFs with end-to-end encryption?
Yes, up to approximately 25 MB per transfer on the free tier. Pro supports larger files. If you need to send a bigger document, compress it first — PDF Pro's compression runs locally and the resulting smaller ciphertext fits a single secure transfer without degrading encryption guarantees.
Send a file the internet can't quietly keep a copy of.
Kein Konto. Kein Upload of readable content. No recovery path — by design.
sendEncrypt and Share