Technical reference
Privacy-first PDF tools: how browser-based processing works
A plain-language technical reference: what happens to your PDF bytes when you use a browser-based tool, why no upload means no leak, and where the limits are.
Published 2026-06-09 · Last checked June 2026
What happens when you open a PDF here
When you drag a PDF onto one of the tools on this site, the following sequence happens entirely inside your browser:
- File picker / drag-and-drop: The browser's
FileAPI reads the file from your disk into an in-memoryArrayBuffer. This is local I/O — no network involved. - WebAssembly processing: The
ArrayBufferis passed to a WebAssembly module (e.g., pdf-lib for form-filling, qpdf-wasm for encryption) running inside your browser tab. WASM modules execute in the same sandboxed environment as JavaScript — they cannot open raw TCP sockets, write to disk, or access other tabs. - Result construction: The WASM module returns a modified
Uint8Array. The page constructs aBlob URLand triggers a browser download — again, entirely local.
At no point does the file's bytes cross a network socket. This is not a policy claim — it is a consequence of how the architecture works.
How to verify this yourself
You don't need to take our word for it. Here is a repeatable, 60-second verification:
- Open any tool on this site (e.g., Fill PDF).
- Open DevTools: F12 on Windows/Linux, ⌘⌥I on Mac.
- Click the Network tab. Set filter to Fetch/XHR.
- Drop a PDF onto the page and complete a conversion.
- Inspect the Network tab. You'll see the initial page assets. You will not see a POST request containing your file.
Browser-based vs. upload-based: an honest comparison
Browser-based is not universally better — each architecture has genuine trade-offs. Here is an accurate comparison:
| Feature | Browser-based (this site) | Upload-based |
|---|---|---|
| Files stay on your device | Yes — files never cross the network | No — file sent to a third-party server |
| Works without an account | Yes | Usually no (free tier often requires login) |
| Works offline after page load | Yes | No |
| File size limits | Set by your device's RAM, not our server | Usually 25–50 MB on free tier |
| Retention risk | None — file never stored on a server | Depends on provider's policy (often 1–24 h) |
| Processing speed | Instant for small files; limited by your CPU for large ones | Depends on server load and upload speed |
| OCR quality at scale | Good for single docs; large models too heavy for the browser | Better for high-volume OCR (server has more compute) |
| Verifiable privacy | Yes — open DevTools, watch Network tab | No — requires trusting the provider's statement |
When we do use a server
One tool on this site uses a server-side component: the OCR PDF tool, when server OCR is selected. In that case:
- The file is transmitted over HTTPS to our processing server.
- OCR is run and the result is returned to your browser.
- The file is deleted immediately after the result is returned. We do not store, log, or share it.
- The tool page is clearly labelled so you know before you upload.
All other tools are client-side only. No file ever leaves your browser for those.
The open-source libraries we use
Every WebAssembly module we ship comes from an open-source project. You can read the source code, review the build process, and confirm we haven't modified the binary:
- pdf-lib — PDF creation and form-filling
- pdfjs-dist — PDF rendering and text extraction (Mozilla)
- qpdf-wasm — PDF encryption and password protection
- heic2any — HEIC/HEIF image decoding
- tesseract.js — In-browser OCR (client-side path)
Frequently asked questions
What does 'files never leave your device' actually mean?
When you open a PDF in a browser-based tool, the browser's File API reads the bytes directly from your disk into an in-memory ArrayBuffer. That buffer is passed to a WebAssembly module running inside the same browser tab. Nothing in that path involves a network request — the bytes never touch a network socket. You can confirm this by opening DevTools → Network and filtering for Fetch/XHR; you'll see the page assets load once, then nothing.
How is this different from a tool like Smallpdf or ILovePDF?
Upload-based tools receive your file on their server, process it, then return the result. Your file exists on a third-party machine during processing — subject to their retention policy, security posture, and legal jurisdiction. Browser-based tools never send the file, so there is no server-side exposure window.
Can I verify that nothing is uploaded?
Yes. Open your browser's DevTools (F12), switch to the Network tab, set the filter to Fetch/XHR or All, then run a conversion. You'll see the initial page assets load. After that, the only network traffic should be analytics events (if any) — never a POST containing your file's contents.
What about the WebAssembly modules — could they phone home?
WASM modules run inside the browser's sandbox and are subject to the same Same-Origin Policy as any other script. A WASM module cannot open a TCP socket directly; it can only make network calls through the browser's fetch/XHR APIs, which appear in DevTools. Every WASM library this site uses is open-source (pdf-lib, pdfjs-dist, qpdf-wasm, heic2any) and can be audited.
Are there any tools on this site that do upload files?
The OCR tool optionally uses a server-side OCR engine for best accuracy — it is clearly labelled. When you use it, the file is sent to our server over HTTPS, processed, and deleted immediately. No file is stored, shared, or retained. All other tools on this site are client-side only.
What about my internet connection — does the tool still work offline?
Yes, once the page has loaded. All processing runs locally in your browser tab using WebAssembly. You can disconnect from the internet after the page finishes loading and the conversion will still complete.
Why don't all PDF tools work this way?
Two reasons: technical difficulty and business model. WebAssembly-based PDF processing is substantially harder to build than server-side pipelines, and the libraries are younger. Also, upload-based tools can gate features behind subscriptions (e.g., batch processing, OCR at scale) in ways that browser-based tools cannot, making the server model commercially attractive to operators.
Want to go deeper?
Our companion explainer covers the threat model in more detail — what the server actually sees, what browser-based tools can and can't protect against, and how to audit a tool you're not sure about.
Read the threat-model explainer →