Don't trust us — check
Verify that nothing is uploaded
Every PDF site says your files are safe. The useful question is not whether we say it, but whether you can check it without believing a word we write. You can, in about two minutes, and here is exactly how.
Check 1 — read the receipt 10 seconds
Run any job on Filozy, then open Processing details
under the result. On a tool you have already used once, the receipt
reads something like
3 pages · 412ms · 0 document bytes sent · 0 network requests during the job.
The first part of that line is us reporting on ourselves. The last part is not. It comes from the browser's Resource Timing API, which keeps its own log of every request a page makes — we read that log before the job starts and again when it finishes, and print the difference. An upload cannot happen without appearing there.
The first time you use a tool the count will not be zero: it will name
the engine and font files this site serves to your device, with their
size. That is the honest shape of it, and we print it rather than hide
it — a zero you can only get by leaving things out is worth nothing.
Run the same tool again and it drops to 0.
What this proves: more than a receipt normally does, because the browser is the one counting. It is still our page printing the number, so the next two checks put the measurement in your hands instead of ours.
Check 2 — watch the network 1 minute
- Open any tool — Merge PDF will do.
- Open developer tools: F12, or Cmd+Option+I on a Mac. Select the Network tab.
- Clear the list, so what follows is only what happens next.
- Now choose your file and run the job.
- Read the list, and sort it by size.
An upload is not subtle. It appears as a POST or
PUT carrying a request body roughly the size of your
document — a 4 MB PDF cannot cross a network as anything smaller
than about 4 MB. You will not find one. What you will find is the
page's own files: scripts, fonts, and the WebAssembly engine that does
the work on your machine.
What this proves: a great deal. The browser is not on our side — it reports every request a page makes, and a website cannot hide one from its own developer tools.
Check 3 — switch off the internet 1 minute
This is the one that ends the argument. A file cannot be uploaded to a server you are not connected to.
- Open a tool and run one job normally, while still connected.
- Now turn off Wi-Fi, or switch on airplane mode. Do not reload the page.
- Choose another file and run the job again.
It completes, and produces your file, with no connection at all. We measured it: in that state the browser attempted zero network requests and still produced the PDF.
Why the first job has to be online, and why we say so. The engine is a WebAssembly file fetched the first time you use a tool, so a tool opened for the very first time with no connection will tell you the engine failed to start. Reloading while offline will not work either — there is no service worker caching the page. We could have left that out and let you discover it; a claim you can catch us overstating is worth less than one that survives you testing it.
What none of this proves
Being straight about the limits is the only reason to trust the rest:
- The site is not silent. Loading a page fetches its HTML, styles, fonts and engine, and the site is served by Cloudflare and uses Cloudflare's cookieless Web Analytics. What never leaves your device is the document — not its contents, not its filename, not its size. The privacy policy lists everything else.
- You cannot read the code. Filozy is closed source. That is a fair reason for scepticism, and it is why this page is about observable behaviour rather than an invitation to read a repository.
- Your device is still your device. Processing locally protects the file in transit and at rest on someone else's server. It does not protect you from malware on your own machine, or from whoever else can use it.
- This is about one site. Run the same checks on any tool that claims local processing. Several are honest. The test does not care who wrote the page.
Questions people ask
How do I know a browser PDF tool is not uploading my file?
Do not take the site's word for it — watch the network. Open your browser's developer tools, switch to the Network tab, then choose your file. An upload appears as a request whose size matches your document. If no such request appears, the file did not leave the machine. The stronger version of the test is to disconnect from the internet entirely and run the tool again: it still works, because the work was never happening anywhere else.
Does Filozy really work with the internet turned off?
Yes, once the page and its engine have loaded. The engine is a WebAssembly file fetched the first time you use a tool, so a tool opened for the very first time with no connection will report that the engine failed to start. Load the page, run one job, then disconnect and run another: it completes normally and the browser makes no network requests at all. That was measured, not assumed.
What does the "0 document bytes sent" receipt actually mean?
Open "Processing details" after a job and the receipt reads something like "3 pages · 412ms · 0 document bytes sent". The last figure counts bytes of your document sent anywhere during the job, and it is zero because the work ran in a Web Worker on your own device. Note what it does not say: that no bytes at all crossed the network. The page itself loaded, and that took bytes. It is also the site reporting on itself, so treat it as a convenience — the Network tab and the offline test are the checks that need no trust.
Does that mean Filozy makes no network requests at all?
No, and it would be dishonest to claim so. Loading the page fetches its HTML, styles, fonts and the engine, like any website, and the site is served by Cloudflare and uses Cloudflare's cookieless Web Analytics. What never leaves your device is the document: not its contents, not its name, not its size. The privacy policy lists everything the site does request.
Is the source code open so I can check it myself?
No — Filozy is closed source, so you cannot audit the code. That is a fair reason to be sceptical, which is exactly why the checks on this page are about observable behaviour instead. A network trace and an offline run tell you what the software does, whoever wrote it and whether or not you can read it.