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.

Chiffré côté client · Partage de PDF

Partage de PDF chiffré côté client, expliqué correctement.

« Chiffré de bout en bout » est utilisé de façon vague. Voici le véritable mécanisme cryptographique derrière un lien de PDF chiffré côté client — AES-256-GCM, gestion de la clé, modes fragment ou phrase secrète, et ce que le serveur ne peut littéralement pas faire. Remarque : « zero-knowledge » sur cette page désigne le fait que le serveur ne détient aucune information susceptible de déchiffrer votre fichier, et non les preuves zero-knowledge formelles (ZKP) — le produit n'utilise pas de ZKP.

lockAES-256-GCM vpn_keyPBKDF2-SHA256 · 310,000 linkFragment ou phrase secrète memoryWeb Crypto API

sendEnvoyer un lien chiffré Comment ça marche

Ce que « zero-knowledge » signifie ici

Une rapide clarification avant tout : ce système n'utilise pas de preuves zero-knowledge (ZKP). L'expression « zero-knowledge » sur cette page désigne la propriété plus faible mais utile en pratique selon laquelle le serveur stockant votre fichier partagé ne possède aucune connaissance — cryptographique ou opérationnelle — qui permettrait de le déchiffrer. La clé ne touche jamais le serveur, donc le serveur ne peut la révéler en aucune circonstance. Le mécanisme est un simple chiffrement côté client plus une clé qui ne voyage que dans le fragment de l'URL (ou est dérivée d'une phrase secrète que le serveur ne voit jamais).

memory

Le chiffrement a lieu dans votre navigateur

Pas sur le serveur, pas dans un worker que vous ne contrôlez pas — dans votre onglet, via window.crypto.subtle. Vérifiable dans les DevTools.

cloud_off

Seul le texte chiffré est envoyé

Le corps de l'upload est du texte chiffré AES-256-GCM. Le PDF, le nom de fichier et les métadonnées n'atteignent jamais le serveur sous forme lisible.

vpn_key

La clé voyage avec le destinataire

Soit dans le fragment d'URL (jamais envoyé aux serveurs), soit dérivée d'une phrase secrète choisie par l'expéditeur. Quoi qu'il en soit, nous ne la voyons jamais.

block

Pas de récupération = pas de porte dérobée

Lien perdu ou phrase secrète oubliée ? Le fichier est définitivement perdu. Comme la clé n'atteint jamais notre serveur, la voie de récupération qui affaiblirait la garantie n'existe tout simplement pas.

Comment un lien de PDF chiffré côté client est construit

Un parcours de ce que font le navigateur de l'expéditeur, le serveur et le navigateur du destinataire — avec les véritables appels Web Crypto.

1 — Navigateur de l'expéditeur

// 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 — Forme du lien de partage

// 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 — Le serveur stocke des octets opaques

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

4 — Navigateur du destinataire

// 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

Mode fragment vs mode phrase secrète

Deux façons d'acheminer la clé au destinataire. Même garantie sur le texte chiffré, compromis différents entre ergonomie et fuite.

Mode Fragment

La clé voyage dans le hash de l'URL (`#`)

Le flux le plus simple : copiez le lien, collez-le dans une conversation au destinataire, c'est fait. La partie de l'URL après # n'est jamais envoyée à un serveur web par un navigateur conforme — c'est ce qui garde la clé privée.

Une seule étape pour le destinataire — cliquer sur le lien.
Peu de friction, adapté à un partage de sensibilité faible à moyenne.
Risque : si le lien fuit via une capture d'écran ou la synchronisation du navigateur, le fichier fuit avec.
À utiliser quand vous faites confiance au canal (messagerie signée, chat interne).

Mode Phrase secrète

Clé dérivée d'une phrase secrète (PBKDF2)

L'expéditeur choisit une phrase secrète. Le navigateur dérive une clé de 256 bits via PBKDF2-SHA256 avec 310 000 itérations sur un sel aléatoire de 128 bits. Le sel est stocké côté serveur ; la phrase secrète est partagée hors bande (téléphone, Signal, en personne).

Partage à deux facteurs : le lien et la phrase secrète voyagent séparément.
Le lien seul ne suffit pas — le texte chiffré reste illisible.
La force de la phrase secrète compte : 310k itérations ralentissent l'attaque par force brute, mais ne sauvent pas une phrase de 6 caractères.
À utiliser quand le lien risque d'être transféré ou stocké quelque part en qui vous n'avez pas pleinement confiance.

Propriété	Mode fragment	Mode phrase secrète
Support de la clé	Hash d'URL (`#`)	Phrase secrète + sel
Le serveur voit-il un jour la clé	Non	Non
Le serveur stocke	Texte chiffré + IV	Texte chiffré + IV + sel
Effort du destinataire	Cliquer sur le lien	Cliquer sur le lien + saisir la phrase secrète
Fuite possible par capture d'écran	Oui (lien = clé)	Non (lien seul inutile)
Résistant à la force brute	Aléatoire 256 bits	Dépend de la phrase secrète
Idéal pour	Partage à faible friction sur canaux de confiance	Partage à plus forte sensibilité

Pourquoi un texte chiffré stocké sur le serveur vous protège quand même

On nous demande souvent : « s'il est sur votre serveur, en quoi est-ce privé ? ». La réponse est que le texte chiffré n'est pas le fichier. Sans la clé, ce ne sont que des octets d'apparence aléatoire. Voici ce que cela signifie en pratique.

storage

Brèche de base de données = fuite de texte chiffré

Si un attaquant compromettait notre base de données, il repartirait avec des octets opaques. Récupérer un seul fichier exigerait une attaque par force brute sur une clé de 256 bits — non faisable selon la physique connue.

gavel

Une assignation produit du texte chiffré

Un tribunal peut nous contraindre à remettre ce que nous possédons. Ce que nous possédons est du texte chiffré. Une décision de justice ne peut pas créer rétroactivement une clé que nous n'avons jamais stockée.

group

L'accès interne est neutralisé

Un employé malveillant avec des identifiants complets sur la base de données ne peut toujours pas lire les fichiers. La garantie est imposée par les mathématiques, pas par le contrôle d'accès.

timer

L'expiration renforce la garantie

Le texte chiffré est supprimé à l'expiration (24 h en gratuit, jusqu'à 30 j en Pro). Après cela, même le texte chiffré disparaît — la seule copie du fichier existe à l'endroit où il a été déchiffré.

warningLimites honnêtes

Le chiffrement côté client ne résout pas la sécurité des terminaux. Un logiciel malveillant sur l'appareil de l'expéditeur ou du destinataire peut voler la clé en mémoire. Une extension de navigateur compromise peut lire le fichier déchiffré. Et un lien transféré dans une conversation de groupe annule toute garantie cryptographique. L'architecture augmente le coût d'une compromission ; elle n'élimine pas tout risque.

Chiffrement côté client vs autres options « sécurisées »

Une comparaison claire des choix courants pour partager un PDF. La plupart des options étiquetées « sécurisées » sont chiffrées en transport — elles protègent les données en transit, mais le serveur récepteur conserve toujours le texte clair et la clé.

Option	TLS en transit	Le serveur peut lire le fichier	Expiration	Compte destinataire
Pièce jointe d'e-mail	Généralement oui	Oui — à chaque saut	Pour toujours	Non requis
Lien de partage cloud générique	Oui	Oui	Facultatif	Parfois
PDF protégé par mot de passe	Oui	Oui (si l'hébergeur a le fichier)	Jamais	Non requis
PDF Pro (mode fragment)	Oui	Non	24 h / 30 j	Non requis
PDF Pro (mode phrase secrète)	Oui	Non	24 h / 30 j	Non requis

Lectures associées

Partage basé sur la confiance vs zero-knowledge course en direct

Même objectif — partager un PDF. Regardez les deux modèles de confiance franchir la ligne d'arrivée côte à côte.

cloud_upload

Partage basé sur la confiance

Le serveur conserve le texte clair

Envoyer le PDF au serveur
Le serveur conserve le texte clairTexte clair
Le serveur promet de supprimerConfiance
Risque de brèche de leur côtéRisque
Le destinataire télécharge du texte clairExposé

Copies en texte clair sur le serveur

Le serveur peut lire

Oui

Clés sur le serveur

Oui

shield_lock

Cet outil

Partage zero-knowledge

Chiffrer le PDF dans le navigateurE2E
Le serveur ne garde que le texte chiffréZero-knowledge
Le destinataire déchiffre localementTerminé

check_circle

Déjà partagé — et le serveur ne peut pas le lire.

Pas de texte clair sur le serveur. Pas de garde de clés. À l'épreuve des brèches par conception.

Copies en texte clair sur le serveur

Le serveur peut lire

Non

Clés sur le serveur

Non

L'animation se joue une seule fois par vue — appuyez sur rejouer pour la revoir.

Questions fréquentes

Que signifie vraiment le partage de PDF chiffré côté client ?

Cela signifie que le serveur qui stocke votre fichier partagé ne peut littéralement pas le déchiffrer. La clé de chiffrement est générée dans le navigateur de l'expéditeur, jamais transmise, et seul le navigateur du destinataire peut la reconstruire — soit depuis le fragment d'URL, soit depuis une phrase secrète partagée hors bande. La garantie est imposée par la cryptographie, et non par une politique de contrôle d'accès que nous pourrions modifier. Remarque : c'est distinct des preuves zero-knowledge formelles (ZKP), que ce produit n'utilise pas.

Quel chiffrement PDF Pro utilise-t-il pour le partage chiffré côté client ?

Chiffrement symétrique AES-256-GCM avec un vecteur d'initialisation aléatoire de 96 bits par fichier. Pour le mode phrase secrète, les clés sont dérivées via PBKDF2-SHA256 avec 310 000 itérations sur un sel aléatoire de 128 bits. Toute la cryptographie s'exécute dans la Web Crypto API native du navigateur.

Quelle est la différence entre le mode fragment et le mode phrase secrète ?

Le mode fragment place la clé de 256 bits dans le hash de l'URL (après #), que les navigateurs n'envoient jamais à aucun serveur. Toute personne disposant du lien complet peut déchiffrer. Le mode phrase secrète dérive la clé d'une phrase secrète choisie par l'expéditeur ; sans elle, le texte chiffré reste illisible. Le mode phrase secrète est plus sûr si le lien fuit ; le mode fragment est plus simple pour un partage à faible friction. Voir le tableau comparatif ci-dessus.

Un fragment d'URL est-il vraiment sûr comme support de clé de chiffrement ?

Les navigateurs conformes ne transmettent jamais la partie fragment d'une URL (la partie après #) au serveur. Elle reste côté client et n'est visible que pour le JavaScript exécuté dans l'onglet du destinataire. C'est ce qui fait du lien de partage lui-même la justificatif de déchiffrement — la clé voyage avec le destinataire, pas avec l'upload. Vous pouvez le vérifier dans l'onglet Réseau de votre navigateur : l'URL de la requête est tronquée à ? ou #.

PDF Pro ou un tribunal peuvent-ils lire les fichiers stockés via le partage chiffré côté client ?

Non. Le serveur stocke du texte chiffré AES-256-GCM plus un vecteur d'initialisation (plus un sel en mode phrase secrète). Sans la clé — que nous n'avons jamais reçue — ces données sont cryptographiquement indiscernables d'octets aléatoires. Nous ne pouvons divulguer que du texte chiffré, qui est ce que nous avons.

Que se passe-t-il si je perds le lien ou oublie la phrase secrète ?

Le fichier est définitivement irrécupérable. C'est intentionnel — le chiffrement côté client signifie aucune voie de récupération, car une telle voie exigerait que nous détenions la clé. Conservez la phrase secrète dans un gestionnaire de mots de passe et gardez le lien dans un endroit pérenne.

Le partage de PDF chiffré côté client est-il gratuit ?

Oui. L'offre gratuite prend en charge le chiffrement AES-256-GCM et une expiration du lien de 24 heures sans inscription. Le plafond de fichier de l'offre gratuite est d'environ 25 Mo par transfert ; Pro étend la fenêtre d'expiration à 30 jours et relève les limites de taille de fichier.

Le destinataire a-t-il besoin d'un compte ?

Non. Le destinataire clique sur le lien, son navigateur déchiffre localement via la Web Crypto API et il télécharge le fichier — aucune inscription, aucune installation, aucun mur de portail entre lui et le fichier.

Envoyez un seul lien chiffré de bout en bout. Laissez-le expirer à l'heure prévue.

Chiffrement AES-256-GCM dans votre navigateur. Aucune inscription, aucun texte clair côté serveur, aucune porte dérobée de récupération.

sendCréer un lien chiffré