Comparison
Browser-based vs cloud file tools
Two websites can offer the identical button — compress this PDF — and be built on opposite architectures. One sends your file to a computer. The other sends a computer program to your file. Almost everything people argue about when they compare free file tools (the size cap, the daily limit, the queue, the privacy policy, the subscription) turns out to be a downstream consequence of that single choice.
This page sets out both models honestly, says where each one wins, and then gives you the check — it takes about thirty seconds — that tells you which one any tool you are looking at actually uses. Including this one.
The two models, side by side
Nothing in this table is a claim about a particular company. Each row follows from where the computation happens, which is why you can check it by reasoning rather than by trusting anyone.
| Question | Server-side (“cloud”) | In the browser |
|---|---|---|
| Where does the work happen? | On hardware the operator owns and you cannot see. | In the tab you already have open, on your own processor. |
| Does your file have to travel? | Yes. A program cannot operate on bytes it has not received. | No. The program travels instead, as part of the page. |
| What decides the maximum file size? | What the operator chooses to allow, because every megabyte costs them. | Your device’s memory. It costs the site nothing either way. |
| What does a daily job limit protect? | The operator’s compute bill, which scales with jobs run. | Nothing, because their bill does not move when you run a hundred jobs. |
| Can the result differ between two people? | No. Everyone gets the same CPU, the same libraries, the same fonts. | Yes. Your browser, your device and your fonts are part of the pipeline. |
| What happens when the site goes down? | Nothing works. | Pages your browser already cached can still work; the rest do not. |
| How big can the processing model be? | Any size. It lives on their machine. | Only as big as is reasonable to download into a tab. |
| What can you verify for yourself? | That the site says what it does. What happens after upload is unobservable from outside. | What the page did, in your own browser’s network panel, while you watched. |
How to tell which one you are using
You do not have to take anybody’s word for this, ours least of all. Your browser will tell you, and the method works on any site:
- 1.Open the developer tools and select the Network panel. In most browsers that is F12, or right-click anywhere on the page and choose Inspect.
- 2.Clear the list, then run the tool on a real file.
- 3.Read what appeared. A server-side tool has to show you a request carrying the file — typically a
POST, with a request body roughly the size of your document, often to a different host than the page. A browser-based tool cannot show you one, because there is nothing to send.
Two things worth knowing so the check stays honest. Entries beginning blob: or data: are in-memory and never leave your device — they are how a browser hands a generated file to the download bar. And a site loading its code, fonts or a model is not sending your file anywhere; look at the direction and the body, not the count.
Run it here and the list stays empty of anything carrying a body, because the browser will not permit one: tool pages on this site are served connect-src 'none', which switches off fetch, XHR, WebSocket, EventSource and sendBeacon at once. We check the same thing adversarially on every release — five deliberate exfiltration attempts, then a real file through a real tool, in two browser engines. Six of six checks passed on 21 September 2026, with 0 bytes recorded to any off-origin host. The protocol and the result.
Two routes are not that, on purpose, and you will see it. The image editor and the background remover are served connect-src 'self' instead, because the background remover has to download its model and WebAssembly runtime before it can run anything. In the Network panel those appear as requests towards your browser from this same origin — application assets, like the scripts and the stylesheet. If you ever see one going the other way with your image in it, that is a vulnerability and we want the report.
Why the limits exist, on both sides
The interesting thing about a file-size cap or a daily job allowance is not that it is mean. It is that it is load-bearing. A service whose costs rise with every megabyte received and every CPU second burned has to meter megabytes and CPU seconds, or it does not survive. The paywall is the cost structure showing through, and it would exist under any management.
When the work happens on your machine, that particular meter is not connected to anything. A 2 GB file costs the site exactly what a 2 KB file costs it. The fiftieth job in an afternoon costs what the first did. This is not a promise to be generous; it is an absence of the thing that makes a cap necessary.
The trade is real, though, and it runs the other way too: a cost that does not scale also cannot buy anything. There is no budget here for a larger model, a faster machine or a support rota, because there is no per-use revenue to pay for one.
Where the browser model loses
We build this way and we still think a server is the right answer for a good number of jobs. Here is the list, and it is not a hedge — every item is a limitation of the site you are reading.
- Big files on small machines
- A document that needs more memory than the tab has will fail here and succeed on a server. On a phone, the ceiling arrives much earlier.
- Heavy models
- Optical character recognition, layout reconstruction and language coverage all scale with model size, and a model has to be downloaded before it can run in a tab. That is why our OCR is English only.
- Reproducibility
- A support answer that begins “it works on my machine” is a structural property of this design, not a bad day. Two browsers can disagree, and an old or unusual one can fail entirely.
- Anything that needs to remember you
- Shared folders, saved templates, retention policies, audit trails, team permissions. None of these exist without a server holding state between visits.
- A first load that is not free
- The code has to arrive before it can run. A server-side tool ships you a thin page and does the heavy part elsewhere.
- Accountability
- A paid service has a company, a support desk and a contract. An open-source project has an issue tracker and whoever is awake.
What neither model can promise you
- That it is bug-free. Evidence about where bytes went is not a security guarantee, and cannot establish that no flaw remains — which is why phrases like “zero data leaks” were removed from this product rather than re-argued.
- That your device is safe. Running the work locally moves the risk to your machine, your browser and your extensions. It does not remove it.
- That nobody knows you visited. Any website, built either way, is requested from a server that records the request. The difference is about your file, not about your visit.
- That today’s answer holds tomorrow. An architecture can change in a release. That is why the check above is worth more than this page: you can re-run it whenever you like.
Try the check on a real job
Open the Network panel first, then run one of these on a document you actually need done. Free, and no account.
Keep reading
- PDF tools that do not upload your file — the thirteen live tools, each with the limit it will not go past.
- Open-source PDF tools you can read and run yourself — the licence, the repository and the container.
- The threat model, if you are deciding this on behalf of other people, and what the visit log records.