Convert PDFs privately: the zero-upload guide

Every document tool asks you to make the same decision, usually without telling you it is a decision: when you drop a file into an online converter, where does it go? For most services the answer is 'to our servers', and what happens there — retention, storage location, model training — is buried in a privacy policy almost nobody reads.

A different architecture quietly solves the whole problem. Zero-upload tools run the conversion inside your browser, so the file never exists anywhere but on your own device. This guide explains what zero-upload really means, why it is the right choice for sensitive work, what it changes about your compliance position, and how to verify a tool is actually local.

This is the architecture nctools uses, so this guide is written from the inside — but the reasoning applies to any tool you evaluate.

What your file is actually worth

It helps to state plainly what is at stake when a document goes to a server. A contract contains counter-party names, deal terms, and possibly personal data. A payroll export contains salaries. A patient letter contains health data. A design file contains an unlaunched product.

Once that file is on someone else's infrastructure, four things become true whether or not you read about them:

• A copy exists you cannot delete or retrieve — 'delete' policies are rarely literal.
• The vendor becomes a data processor, creating obligations on both sides.
• A retention window and a transfer route exist, often across borders.
• The content may be used for improving the vendor's products — including the models it sells.

None of this is malicious by default. It is the economics of running servers and selling conversion services. But it is a real cost you are paying every time you upload, and most free tools simply monetise uploaded documents to fund the 'free' tier.

How zero-upload conversion works

The technology behind local conversion is not exotic. Decades of browser-side programming have converged on WebAssembly for exactly this kind of work, and the proven libraries are open source.

1. Parsing — the PDF is read locally with a browser-based parser (Mozilla's pdfjs-dist), the same engine inside Firefox.
2. Extraction — text, layout, and images are pulled from the file on your device.
3. Recognition — OCR runs on-device via Tesseract compiled to WebAssembly, with language models cached locally.
4. Building — the output (Word, Excel, searchable PDF) is generated locally from the extracted content.
5. Downloading — the result appears in your browser's Downloads folder. Your device did all the work.

At no point during any of those stages does the document travel over the network. The only requests a genuinely local tool makes are for its own static assets — HTML, JavaScript, fonts — which carry none of your content.

What zero-upload changes for compliance

For teams under GDPR, SOC 2, or client-side privacy obligations, the zero-upload property is not a feature — it is the deciding factor.

No processor relationship

Under GDPR Article 4, a processor is an entity that processes personal data on a controller's behalf. If no personal data ever reaches a tool's systems, there is no processing, no processor, and therefore no requirement for a Data Processing Agreement, no sub-processor list to disclose, and no need to vet a cross-border transfer.

No cross-border transfer

The Schrems II ruling and its successors made US-based processing legally expensive for EU controllers. In-browser conversion sidesteps the entire question: there is no transfer to justify, because nothing moves.

Defensible audit answers

When a DPO or procurement team asks 'where is our data processed and for how long is it retained?', the answer for a server tool is a paragraph of caveats. The answer for a zero-upload tool is: nowhere, and for zero seconds. The security page documents the platform's posture and reproducibility, and our checklist for legal teams handling PDFs walks through the audit questions in full.

Verifying the no-upload claim

You should not take any vendor's privacy promise at face value, including ours. The good news is that verification is straightforward and takes two minutes.

1. Open your browser's Developer Tools and switch to the Network panel.
2. Run a conversion — drop a file and let it process.
3. Filter the request list to show what was sent. Look for any POST or PUT carrying your document.
4. Inspect the largest requests — a genuine conversion reads the file locally, so nothing large should leave.
5. Search for your filename or a distinctive string from the file in the request bodies — it should not appear.

If every request is a static asset and your file never appears, the tool is local. If you see your document uploaded, you have your answer — and it is the same answer for every tool that refuses to document the flow.

When upload is unavoidable

Honesty requires acknowledging where a server still adds value. Not everything can or should be local.

• Extreme document sizes from low-end devices — a very large file on a weak laptop processes faster on a server.
• Collaborative processing — if a team needs a shared, server-side conversion history, that is a product decision, not a technical necessity.
• Guaranteed processing capacity — server farms offer near-unlimited burst compute for huge batches.
• Non-sensitive bulk work — if a document contains nothing sensitive, the upload trade-off may be acceptable for convenience.

The principled approach is to default to local for everything and opt into upload deliberately, document-by-document, only when a genuine reason exists — rather than the reverse, which is how most people use converters today.

Practical guidance for buying or building

Whether you are evaluating a tool for your team or building one, the same checklist applies.

• Confirm the architecture — does the conversion run in the browser or on a server? Ask directly; many products blur this.
• Read the network flow — inspect what leaves the page during a real conversion.
• Check language support — local OCR still needs your language's model; ensure it is covered.
• Test on your real files — a pristine demo never reveals the documents you actually handle.
• Review the retention story — for a genuinely local tool, there is nothing to retain and the answer should be clean.
• Verify the source — open-source engines can be audited rather than trusted.

For teams wanting to run conversion inside their own application, the developers page describes the building blocks and self-hosting, and the documentation covers configuration. The downloads page has the browser extension for converting from any page.

The productivity case for private conversion

Privacy is the headline benefit, but zero-upload conversion is also faster, which is a quieter advantage that compounds in daily use.

Because the file does not travel to a server and back, in-browser conversion removes the network round-trip — for typical documents it is measurably faster than the equivalent upload workflow, and there is no queue, no cold start, and no rate limit imposed by a server farm. You can also work offline once the app shell is loaded.

The PDF workflow for professionals guide builds on this to show how a private, local-first toolchain compresses an entire document day. The principles there — sensors first, one tool per job, keep it repeatable — all get easier when nothing is uploaded.

What auditors and DPOs actually ask

When a security team or DPO evaluates a conversion tool, the questions sound abstract until you realise they reduce to a short list with concrete answers. Understanding the expected answers helps you evaluate any vendor, including us.

• Where is our data processed? Expected answer for a zero-upload tool: in the user's browser, on their device, nowhere else.
• Which sub-processors touch our files? Expected answer: none for the conversion path — there is no server in the loop.
• How long is our data retained? Expected answer: zero seconds for documents — they never arrive, so there is nothing to retain.
• Is there a Data Processing Agreement? Expected answer: not required for conversion, because no processing happens on our behalf.
• Can you prove it? Expected answer: yes — run a network trace, inspect the open-source components, pin a release.

These answers are not marketing; they follow directly from an architecture where the conversion never touches a server. That is why zero-upload tools routinely pass privacy reviews in a fraction of the time a server-based alternative takes, and why the compliance checklist for legal teams keeps returning to the same point.

The precise boundary: documents versus account data

The zero-upload claim is powerful precisely because it is precise, and precision matters more than hype in a compliance conversation. It is worth stating the boundary exactly so nobody overstates it.

Document contents — the bytes of your PDF, Word, spreadsheet, scan, or image — never leave your device. That is the zero-upload property, and it is the part auditors care about. Separately, there is an account layer: if you sign in, manage a workspace, or use a paid plan, basic account data (email, workspace name, subscription state, billing status) is processed by the platform's managed backend, and that is documented in the privacy policy and covered by ordinary agreements.

The reason this distinction is so valuable is that it maps cleanly onto the GDPR categories. Document contents are not processed at all, so they raise no processing question. Account data is processed, but it is ordinary contact-and-billing information with a clear controller relationship. No regulatory grey zone survives the distinction — which is itself a strong governance signal for any team that has spent months stalled on a 'but where do our files go?' question.

Practical evaluation questions for anyone buying

If you are choosing a converter for a sensitive environment, skip the feature-list marketing and ask the questions that actually reveal the architecture. You do not need to be a security engineer to run this screen.

1. Run a real conversion with the Network panel open — does the document actually leave the page? This is the honest test.
2. Ask directly whether the conversion runs in the browser or on a server, and ask for the architecture in writing.
3. Check whether the tool loads language models or engines locally, which is what makes browser-side processing possible.
4. Read the retention language around 'files' or 'uploads' — a genuinely local tool should have nothing to say here.
5. Ask what happens on a subpoena or court order — for a zero-upload tool, the honest answer is 'we have nothing to hand over'.
6. Confirm the output too — does the generated Word, Excel, or PDF stay on your device?

Two vendors can describe themselves surprisingly similarly while placing very different bets on your documents; these questions separate them cleanly. The security page answers them for our tool, but the checklist works for any candidate.

Why procurement and risk teams are starting to prefer local

There is a noticeable shift in procurement behaviour over the past few years, and zero-upload tools are a beneficiary. Risk teams that once waved through any server-based converter have grown wary of the accumulating details — the retention windows, the sub-processor lists, the cross-border transfer paperwork.

A local tool removes most of that paperwork by removing its subject. There is no transfer to justify, no processor to vet, and no retention policy to reconcile with the organisation's records schedule. Procurement still checks the account-layer data handling and the security posture, but the hardest category — 'what happens to our documents' — simply does not arise. That is why the privacy-first PDF workflow resonates with teams that value both speed and a cleaner risk profile.

Hardening the device side

Zero-upload moves risk from the vendor onto your own device, which is a trade worth making but still deserves attention. A few habits keep the local surface tight.

• Process sensitive files on managed, up-to-date devices — patched browsers and updated engines close the classes of vulnerability that matter for local processing.
• Clear the downloads and temporary files when you are done with a sensitive conversion — the local copy should not outlive the job.
• Keep the tool itself up to date so engine fixes and security patches reach you.
• Apply the same endpoint controls you already use for other sensitive work — full-disk encryption and lock-on-suspend cover the file on disk.

None of these are burdensome; they are the same habits you already apply to the sensitive files on your computer. The point is simply that 'local' is not 'magic' — it moves responsibility to a place you already manage, which is exactly why so many organisations prefer it over placing documents on infrastructure they can never inspect.

A final perspective

The document conversion market grew up in an era when browsers could barely parse images, and server-side processing was the only way to get the job done. That era is over. WebAssembly and a decade of open-source effort moved serious document processing onto the device, and with it removed the largest privacy and compliance cost of the workflow.

Reference models matter here. Local tools were once viewed by procurement and DPO teams as a novelty; in 2026 they are increasingly the default, precisely because they are the only option with nothing to disclose. For anything confidential, the sensible choice is the tool that never sees the file.

If your work involves sensitive documents, start your own private conversion habit with the tools on the tool box page — PDF to Word, PDF to Excel, PDF to OCR, and more. Everything is zero-upload by construction, and each pairs with a guide on the blog.