Why your files never leave the browser, and what that costs

On 9 November we audited our PDF tools: pdfresult and pdfsuperb at 1280, 768 and 390 pixels wide and in WebKit on an iPhone profile, in five languages, on 12 tools. One finding was a file larger than the 60 MB limit that was silently ignored. Nothing happened, and the page gave no reason.

It is a small bug, and it comes straight from how our sites work. There is no server that could accept a large file and report back. The browser tab has to check the file itself, and the page has to explain the limit itself. We fixed that one. Below is the rest of the trade: what stays on your device, what it costs you, and what our sites do send.

Where the file goes

Every PDF tool on our sites, the OCR pages and the Office converters work on the file inside the browser tab. The file is read from your disk into the page, processed there, and offered back as a download.

What	Goes over the network?	Details
Your PDF, image or Office file	No	Processed in a background worker or on the page itself
Tool code, the PDF worker, fonts, the HarfBuzz font program	Downloaded from the same site	Plain GET requests for our own files
OCR engine files	Downloaded from the same site	About 26 MB on first use, plus the data for the chosen language
Office converter files	Downloaded from the same site	About 84 MB on first use, then reused in the browser session
QPDF program	Downloaded only for PDFs that carry print or copy restrictions	About 3 MB
Anonymous action counters	Yes, on five PDF sites	Fields described below; no file data
Page-view analytics	Yes	Cloudflare zone Web Analytics on laboratoru.com and on the storefronts where it is switched on, with European visitors excluded

We checked the first row in code. Every PDF workspace task runs either in the PDF worker (pdf-lib) or as a canvas job on the page (PDF.js). Their only requests are same-origin GETs for scripts, the worker, fonts and the HarfBuzz WebAssembly file. A browser test records the requests of a Merge PDF visit on a local build of the pdfresult site, and it finds only same-origin GETs.

Since the 11 November release, a finished run on our PDF sites shows: “Your file was not sent anywhere — it was processed in this browser tab.” We worded it about the file on purpose. The sites do send anonymous statistics, so a line saying “nothing is sent” would be false.

Next to it is a way to check: “Want to check? Turn off the internet and run it again.” The hint appears only after a finished run, when the tool code is already in the browser cache. When we measured pdfresult.com on 9 November, it told the browser to keep these files for 4 hours. After that, or with the cache turned off, an offline re-run fails with the usual error. A re-run with other settings may also need a font that was not loaded yet.

One case does keep a local copy. The Office converter can only be stopped by reloading the page, so Cancel stores the chosen document in the browser’s own IndexedDB for that one reload. It is deleted when read back and ignored after 2 minutes. It stays on your device.

What it costs

A browser tab has less memory than a server, so every task has a limit. Merge PDF takes up to 60 MB in total. Compress PDF takes one file up to 60 MB and 200 pages, PDF to Word 10 MB and 100 pages, and scanned PDF to text 10 MB and 10 pages. A file exactly at a limit is accepted. Since the November fixes, a refusal names the file, its count and the limit, and page limits are checked right after selection, before Run.

OCR and the Office converters need their engines in the tab before they can start. On a slow connection the 84 MB for the converter takes a while, and the page shows a progress bar while it loads.

Your device sets the speed. The audit timed DOCX conversion at 6 to 18 seconds with no progress shown. The Office pages now show progress and a Cancel button. OCR stops a step after 90 seconds and says the processing timed out. We have not measured phone memory or time on large files yet.

What our sites send

Five PDF sites send counters to one collector that we run on Cloudflare Workers: pdflino.com, pdfrally.com, pdfsuperb.com, pdfresult.com and datumpdf.com. Each event is a JSON body of at most 1,024 bytes. It carries the schema version, site, task and tool ID, page language and build revision. It names the action: task selected, attempt started, completed, failed or cancelled, download clicked, or a “Useful” or “Needs work” vote. A failure also carries a coarse reason, such as too large, unsupported, corrupt or empty.

The collector stores one row per UTC day, site, task, tool, language, action and reason, with a count. It keeps no raw events, timestamps, file data, IP column, or user or session identifiers. Counters are deleted after 90 days. Requests from the EEA, the UK, Switzerland or an unknown country are dropped before storage, and so are requests with Do Not Track or Global Privacy Control. Local builds, automated browsers and pages opened with ?measurement=off send nothing. A failed send never interrupts processing.

We switched the collector on on 22 September 2026. Probes that day confirmed that unknown origins are rejected, that DNT and GPC requests are dropped and that the counters started empty.

The Laboratory sends less: the two feedback votes for its tools, and attempt counters for its internet and device test pages. Those events carry no IP address, speeds, latencies, device names or results. Its PDF workspace sends no action events.

There is one thing we cannot promise. Cloudflare still receives connection metadata when a request arrives. We turned off application logs and Worker observability, but that does not mean the provider logs nothing.

To see it yourself, run Merge PDF on two files, turn off your connection and run it again. The Network tab in your browser’s developer tools shows every request the page makes.

Merge PDF is in the Laboratory’s PDF workspace on laboratoru.com.