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.

客户端加密 · PDF分享

客户端加密PDF分享，原理清晰透明。

「端对端加密」常被随意使用。以下是客户端加密PDF链接背后真实的密码学机制——AES-256-GCM、密钥处理方式、片段模式与密码短语模式，以及服务器实际上无法做到的事。注意：本页中「零知识」指服务器不持有任何可解密你文件的信息，而非正式的零知识证明（ZKP）——本产品不使用ZKP。

lockAES-256-GCM vpn_keyPBKDF2-SHA256 · 310,000 link片段或密码短语 memoryWeb Crypto API

send发送加密链接了解工作原理

本页「零知识」的含义

先做一个快速说明：本系统不使用零知识证明（ZKP）。本页中「零知识」指的是一个更弱但实际有用的属性——存储你共享文件的服务器在密码学和操作层面都无法解密它。密钥从未接触服务器，因此服务器在任何情况下都无法泄露密钥。机制是纯粹的客户端加密，加上仅在URL片段中传输的密钥（或由服务器从未见过的密码短语派生）。

memory

加密在你的浏览器中进行

不在服务器上，也不在你无法控制的worker中——在你的标签页里，通过window.crypto.subtle完成。可在DevTools中验证。

cloud_off

仅上传密文

上传内容为AES-256-GCM密文。PDF文件、文件名和元数据从不以可读形式传至服务器。

vpn_key

密钥随接收方传递

密钥存于URL片段中（从不发送至服务器），或由发送方选定的密码短语派生。无论哪种方式，我们都无法看到密钥。

block

无找回 = 无后门

丢失链接或忘记密码短语？文件将永久无法恢复。因为密钥从未到达我们的服务器，理论上会削弱安全保证的找回路径根本不存在。

客户端加密PDF链接的构建过程

详解发送方浏览器、服务器和接收方浏览器各自的操作——附实际Web Crypto调用。

1 — 发送方浏览器

// 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 — 分享链接结构

// 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 — 服务器存储不透明字节

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

4 — 接收方浏览器

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

片段模式 vs 密码短语模式

两种将密钥传递给接收方的方式。密文保证相同，但易用性与泄露风险各有权衡。

片段模式

密钥存于URL哈希（`#`）中

最简单的流程：复制链接，粘贴发送给接收方，完成。URL中#后的部分从不被任何合规浏览器发送至任何Web服务器——这正是密钥保持私密的原因。

接收方只需一步——点击链接。
操作简便，适合低至中等敏感度的分享。
风险：若链接通过截图或浏览器同步泄露，文件也随之泄露。
适用于信任传输渠道时（加密通讯软件、内部聊天）。

密码短语模式

密钥由密码短语派生（PBKDF2）

发送方选定密码短语。浏览器通过PBKDF2-SHA256，使用随机128位盐值进行310,000次迭代，派生出256位密钥。盐值存于服务器端；密码短语通过带外方式共享（电话、Signal、面对面）。

双因素分享：链接和密码短语分别传递。
仅有链接不够——密文无法读取。
密码短语强度很重要：310,000次迭代可减缓暴力破解，但无法拯救6位字符的弱密码。
当链接可能被转发或存储在你不完全信任的地方时使用。

属性	片段模式	密码短语模式
密钥载体	URL哈希（`#`）	密码短语 + 盐值
服务器是否见过密钥	否	否
服务器存储内容	密文 + IV	密文 + IV + 盐值
接收方操作难度	点击链接	点击链接 + 输入密码短语
可通过截图泄露	是（链接即密钥）	否（仅链接无用）
抗暴力破解	256位随机数	取决于密码短语
最适合	通过可信渠道低摩擦分享	较高敏感度的分享

服务器存储密文仍能保护你的原因

人们常问：「如果文件在你的服务器上，怎么可能是私密的？」答案是密文不是文件本身。没有密钥，它只是看起来像随机字节。以下是这在实践中意味着什么。

storage

数据库泄露 = 密文泄露

若攻击者入侵我们的数据库，他们得到的只是不透明的字节。破解单个文件需要暴力破解256位密钥——以已知物理条件来说不可行。

gavel

传票只能获得密文

法院可以强制我们交出所持有的内容。我们持有的是密文。法院命令无法追溯创建一个我们从未存储过的密钥。

group

内部访问被中和

拥有完整数据库凭据的内部恶意员工仍无法读取文件。这一保证由数学而非访问控制来执行。

timer

过期机制加强保证

密文在到期时删除（免费版24小时，Pro版最长30天）。之后，即使密文也消失了——文件的唯一副本仅存在于被解密的地方。

warning诚实的局限性

客户端加密无法解决端点安全问题。发送方或接收方设备上的恶意软件可以从内存中窃取密钥。被攻击的浏览器扩展可以读取解密后的文件。在群聊中转发链接会使所有密码学保证失效。该架构提高了遭受攻击的成本，但并不能消除所有风险。

客户端加密 vs 其他「安全」选项

常见PDF分享方式的清晰对比。大多数标榜「安全」的选项仅使用传输加密——它们保护传输中的数据，但接收方服务器仍持有明文和密钥。

选项	传输中TLS	服务器可读取文件	过期	接收方账户
邮件附件	通常是	是——每个节点都可以	永久	不需要
通用云分享链接	是	是	可选	有时
密码保护的PDF	是	是（若主机持有文件）	从不	不需要
PDF Pro（片段模式）	是	否	24小时 / 30天	不需要
PDF Pro（密码短语模式）	是	否	24小时 / 30天	不需要

需要信任的分享 vs 零知识实时竞赛

同一目标——分享PDF。并排观察两种信任模型的完成过程。

cloud_upload

需要信任的分享

服务器持有明文

将PDF上传至服务器
服务器持有明文明文
服务器承诺删除信任
对方存在泄露风险风险
接收方下载明文已暴露

服务器明文副本

服务器可读取

是

服务器上的密钥

是

shield_lock

本工具

零知识分享

在浏览器中加密PDFE2E
服务器仅持有密文零知识
接收方本地解密完成

check_circle

已分享——服务器无法读取。

服务器上无明文。无密钥托管。架构上防泄露。

服务器明文副本

服务器可读取

否

服务器上的密钥

否

动画每次查看播放一次——点击重播再次观看。

常见问题

客户端加密PDF分享究竟意味着什么？

这意味着存储你共享文件的服务器在字面意义上无法解密它。加密密钥在发送方浏览器中生成，从不上传，只有接收方的浏览器才能重建它——无论是从URL片段还是从发送方带外共享的密码短语。这一保证由密码学而非可被更改的访问控制策略来执行。注意：这与正式的零知识证明（ZKP）不同，本产品不使用ZKP。

PDF Pro的客户端加密分享使用什么加密方式？

每个文件使用96位随机初始化向量的AES-256-GCM对称加密。密码短语模式下，密钥通过PBKDF2-SHA256使用128位随机盐值进行310,000次迭代派生。所有密码学运算在浏览器原生Web Crypto API中执行。

片段模式和密码短语模式有什么区别？

片段模式将256位密钥置于URL哈希（#之后）中，浏览器从不将其发送至任何服务器。拥有完整链接的任何人都可以解密。密码短语模式从发送方选定的密码短语派生密钥；没有密码短语，密文保持不可读。若链接泄露，密码短语模式更安全；片段模式更适合低摩擦分享。请参阅上方对比表。

URL片段作为加密密钥载体真的安全吗？

合规浏览器从不将URL的片段部分（#之后的部分）传输至服务器。它仅存在于客户端，只对接收方标签页中运行的JavaScript可见。这正是分享链接本身成为解密凭据的原因——密钥随接收方传递，而非随上传传递。你可以在浏览器的网络面板中验证：请求URL在?或#处被截断。

PDF Pro或法院可以读取通过客户端加密分享存储的文件吗？

不能。服务器存储AES-256-GCM密文及初始化向量（密码短语模式下还有盐值）。没有密钥——我们从未收到密钥——这些数据在密码学上与随机字节无法区分。我们只能披露密文，这就是我们所拥有的。

如果我丢失链接或忘记密码短语会怎样？

文件将永久无法恢复。这是有意为之的设计——客户端加密意味着没有找回路径，因为找回路径需要我们持有密钥。请将密码短语保存在密码管理器中，并将链接存储在可靠的地方。

客户端加密PDF分享是免费的吗？

是的。免费版支持AES-256-GCM加密和24小时链接过期，无需注册。免费版文件上限约为每次传输25 MB；Pro版将过期窗口延长至30天并提高文件大小限制。

接收方需要账户吗？

不需要。接收方点击链接，其浏览器通过Web Crypto API本地解密，然后下载文件——无需注册、无需安装、无任何门槛。

发送一条端对端加密链接，按时自动过期。

浏览器内AES-256-GCM加密。无需注册，服务器无明文，无找回后门。

send创建加密链接