How AttachKit handles your files: the zero-upload privacy model
What happens to your PDF when you use AttachKit: every tool processes the file inside your browser, the only exception is the end-to-end-encrypted send-for-signature flow, and every claim is something you can check yourself.
Last updated
AttachKit's core promise is simple: your PDF is processed in your browser, not on our servers. This article explains what that means in practice, the one deliberate exception, and how to verify each claim yourself.
The zero-upload model
When you fill, sign, redact, compress, convert, or otherwise edit a PDF with AttachKit, the file's bytes are parsed and rewritten entirely inside the browser tab you have open. The work is done by JavaScript PDF engines (pdf-lib and pdf.js) plus WebAssembly modules for the heavy jobs — Tesseract for OCR and qpdf for protected files. The PDF is never uploaded, stored, or transmitted, and for most tools the server isn't even contacted after the page loads.
What leaves your browser, tool by tool
| What you're doing | What leaves your browser |
|---|---|
| Filling, signing, or redacting manually | Nothing — the PDF and your input stay in-page |
| Page edits, compress, watermark, conversions | Nothing — all client-side |
| OCR (Make searchable) | Nothing from your document — only OCR training data may be downloaded, never your scan |
| Auto-fill from profile (AI) | Form-field names and types plus your saved profile values — not the PDF bytes |
| Scan for PII (AI, in Redact) | Text spans extracted on your device; the coordinates stay local — not the PDF bytes |
| AI clause review | Extracted document text — no coordinates, no bytes |
| Counsel Mode (a Max feature — free during the private beta when you're signed in) | Nothing — AI runs against a local Ollama instance you control |
| Send for signature | The encrypted PDF as AES-GCM-256 ciphertext, plus recipient email addresses and the file name — see below |
| Signing in or paying | Your email and standard payment metadata |
The bold rows are the only paths where any document-derived data leaves your machine. For the three AI rows it's text extracted client-side, never the file itself; those requests go to AttachKit's AI sub-processor, Anthropic (the Claude API) — the request and response aren't logged, the commercial API doesn't train on them, and every AI feature runs only when you click it. Send for signature is the encrypted-upload exception, covered next.
The one exception: send for signature
Sending a document to someone else to sign is the only flow where your PDF reaches AttachKit's server at all — and only as ciphertext the server cannot read:
- Your browser generates a random 256-bit AES-GCM key using the browser's built-in WebCrypto.
- The PDF is encrypted in-page; only the ciphertext leaves the tab.
- By default, the recipient link looks like
…/sign/<id>#k=<key>. The part after#is the decryption key, and browsers never include URL fragments in HTTP requests — so the server only ever sees the path, never the key. - The recipient's browser reads the key from the fragment, downloads the ciphertext, and decrypts it locally. After they sign, the result is re-encrypted with the same key before upload.
The trade-off, stated plainly: anyone holding the full link (including the part after #) can decrypt and sign while the request is pending, so treat the link like a password. (Max accounts can switch to zero-knowledge sending instead, which wraps the key to the recipient's published encryption key so the link carries no key at all.) Requests expire after 7 days, and an automatic daily sweep deletes the ciphertext once they do; you can also revoke a pending request from your dashboard, which makes the link stop working immediately.
What AttachKit does store
- Your account email, if you sign in.
- The profile fields you explicitly save at /account/profile for auto-filling forms (kept in your browser's localStorage when you're signed out).
- Short-lived web-server request logs (IP, browser type, timestamp) for abuse prevention — kept up to 30 days.
- Never your PDF bytes — the one exception is the send-for-signature ciphertext above, which the server cannot decrypt and deletes after expiry. There is no readable document store to breach.
You can export everything AttachKit holds about you as JSON, or permanently delete your account, self-service at /account.
Verify it yourself
Don't take this on faith — each claim takes about a minute to check:
- Open your browser's DevTools, switch to the Network tab, load Sign, drop a PDF, sign it, and download. Filter by Fetch/XHR: no request carries your PDF.
- Click an AI feature and inspect that request's payload — you'll see field names or text snippets as JSON, no file bytes.
- Load a tool page once, set the Network tab to Offline, and keep working. Filling, signing, and downloading still work; only the AI features (which need the network) fail.
For the full technical write-up — cryptography, headers, and the complete local-vs-server table — see the security page. The plain-English policy, including retention periods and your GDPR/CCPA rights, is at privacy.
Related
- Encrypted PDFs explained — what happens when a file itself is password-protected
- Scanned PDFs and OCR — how image-only documents are read without leaving your device
Related
Still stuck? Contact support →