Architecture, not policy
How local processing works — and how to check we mean it.
Most PDF sites ask you to trust a privacy policy. This one asks you to open your Network panel. Here is what happens to a file when you use a tool here, how processing assets load, and how optional content-free measurement differs from a document upload.
The path your file takes
Five steps, none of them a server
- 01
Your file
Sitting on your own disk, selected by you through the browser’s own file picker.
- 02
Your browser
Reads the bytes into the tab’s memory. This is a local disk read, not a network transfer.
- 03
The PDF engine
JavaScript and WebAssembly running in this tab parse and transform the document.
- 04
The result
A new file assembled in memory, still inside the tab, still on your machine.
- 05
Download
The browser is asked to save a locally generated result. No document round trip; the site cannot confirm the final save.
Notice what is absent: there is no step where the document is transmitted, queued, stored, scanned or deleted. Those steps cannot leak, because they do not exist.
Don’t take our word
Verify it in about thirty seconds
This is the part we would most like you to actually do. A privacy claim you can test is worth more than one you have to believe.
Watch the network
Open developer tools and select Network. Clear it, then run a tool. Inspect the requests: code and assets may download; with consent, anonymous event reports may be sent. No request should carry your document, filename, text or processing options.
Pull the plug
First load the relevant processing engine and required assets using a non-sensitive sample, then try offline in the same tab. Engines load on demand, so opening the page alone is not enough. Missing assets can prevent an offline run; analytics unavailability cannot prevent local processing.
Read the source
View the page source and the JavaScript it loads. The PDF work is done by libraries running in the page — pdf-lib, pdf.js and Tesseract compiled to WebAssembly — not by calls to an API.
Additional processing assets
OCR downloads an engine. That is not an upload.
Of the 140 tools here, 131 are classified as local processing. The 9 OCR tools also need recognition assets and are badged accordingly. All tools can lazy-load their engine code; this classification is not a promise of zero network traffic.
To recognise text in a scan, your browser needs a recognition engine and a trained model for the language you chose. These static assets arrive from their configured sources and may be cached by your browser. The document is read from your disk and processed locally. Assets failing to load are a processing limitation, not a reason to upload the document.
- Travels to you
- Recognition engine, language model, the site’s own code
- Travels from you
- Optional consented, anonymous tool events — never your document, text, password or signature.
Commitments we can actually keep
Things this site does not do
No file uploads
No tool transmits your document to a server for processing.
No document storage
There is no bucket, queue or temporary directory holding your files. Consented content-free activity is stored separately as aggregates.
No training
Your documents cannot be used to train anything, because we never receive them.
No content in analytics
Document text, metadata, filenames and passwords are never sent to any analytics service.
No account wall
No email address, no sign-up, no verification step before you can use a tool.
No password cracking
We will not build brute-force or bypass tooling, for any reason.
No watermarks
Your output is your document, unbranded.
No dark patterns
No fake download buttons, no fake alerts, no ads placed to catch a misclick.
Questions about local processing
How can I verify that nothing is uploaded?
Open the Network panel in your browser’s developer tools before running a tool. Inspect requests and payloads: lazy-loaded engines and assets arrive at your device, and consented content-free events may leave it, but your document, filename, text and options are not uploaded. An offline check requires the relevant engine and assets to have loaded first; merely opening a tool page does not preload every processor.
Why do OCR tools download something?
Optical character recognition needs a WebAssembly recognition engine and trained language model, downloaded from the configured asset sources. These are static files travelling to your device, not documents travelling away from it. Availability depends on those assets loading successfully under the site’s security policy; your document is never part of the request.
Is local processing actually better, or just a marketing angle?
It is a genuine architectural difference with real trade-offs, not a slogan. The benefit is that documents are not entrusted to a server-side retention policy: no document copy arrives there. Optional content-free activity reports are separate and have their own retention rules. The cost is that your device does the work: very large files are constrained by browser memory, OCR is slower than a server farm, and a few conversions that need heavy native toolchains are simply not offered here rather than faked.
What about the file size limit?
A browser tab has a bounded memory budget, and exceeding it crashes the tab mid-task. We cap input at 250 MB per file so failures are predictable and explained rather than abrupt. Server-based services accept larger files precisely because the memory being spent is theirs, not yours.
Do you log anything at all?
With analytics consent, the first-party service aggregates tool views/clicks, operation starts, reported outcomes, download actions and fixed safe failure codes. It receives no filenames, document text, options, arbitrary error messages or visitor identifiers. Minute totals last 200 days, daily totals remain, grouped failure details last 90 days, and hashed random delivery receipts expire after 24 hours. Host request logs are a separate deployment responsibility. Optional GA and ads also require consent and non-admin eligibility.