Two tool sites can look identical and behave completely differently: one processes your file inside the tab you already have open, the other copies it to a server somewhere and sends back a result. Nothing on either page tells you which one you are using. That ambiguity is the whole problem, because the difference matters enormously — for a passport scan, a signed contract, an invoice, or anything with a customer name in it.
This site is built the first way. That is a deliberate architectural choice, not a marketing claim, and it comes with real advantages and real limits. Both are worth understanding before you decide where to put your documents.
Uploading is the historical default
When most of these tools were first built, the browser could not do much. It could display a form, post it to a server, and render whatever came back. Any real work — resizing an image, parsing a PDF, reading text — happened on a machine in a data centre, because the client could not be trusted with it and often could not perform it at all.
That constraint shaped an entire generation of tools, and the pattern stuck even after the constraint disappeared. If you go looking for an online image compressor today, the odds are good that it uploads your file, because it was written from a template that assumed it must.
The practical consequence is that "online tool" and "your file is now on someone else's disk" have become near-synonyms, and most people have quietly accepted that.
What the browser can actually do now
The reason it no longer has to be that way is a set of capabilities that arrived gradually and are now available in every current browser.
- Canvas and OffscreenCanvas. Draw, scale, rotate and re-encode images without a server — including on a background thread so the interface stays responsive.
- WebAssembly. Run compiled native code — encoders, PDF parsers, OCR engines, text extractors — at a fraction of the speed of JavaScript, still inside the tab.
- The File API and Blob URLs. Read a file the user selected without ever transmitting it, and hand back a finished result as a download.
- WebCodecs and MediaRecorder. Encode and decode audio and video locally, which is what makes in-browser screen recording possible at all.
- Web Workers. Keep long jobs off the main thread, so a hundred-image batch does not freeze the page.
Put together, these cover most of what a general-purpose file tool needs. The exceptions are covered in a later section, and they are narrower than most people assume.
Three architectures, not two
"Local versus uploaded" is too coarse a distinction, because there is a middle case that generates most of the confusion. In practice a tool page is doing one of three things.
- Runs entirely in the tab. Your file never leaves the device. Compressing a JPEG, merging PDFs, formatting JSON and converting a timestamp all belong here.
- Runs a model in the tab. Still local, but the browser downloads a model file the first time — often tens of megabytes — and caches it. Background removal and OCR typically work this way. Your file stays put; the code arrives instead.
- Calls a server. The work genuinely requires a large model or a paid API, and something has to be sent. Rewriting a paragraph, summarising a document and generating a meta description are the usual examples.
The third category is legitimate — some jobs simply cannot run in a browser tab yet. The point is not that every tool must be local. The point is that you should be able to find out which of the three you are using, and that the answer should not require reading a privacy policy written by a lawyer.
How to tell in about ninety seconds
You do not need to trust anyone's badge. Open the page, press F12, and switch to the Network tab. Then select a file and watch what happens.
- Look for a POST request whose body is roughly the size of your file. If one appears the moment you pick a file, the file is being uploaded.
- Filter by "Fetch/XHR" and look at the payload sizes. A request of a few hundred bytes is a settings object. A request of three megabytes is your photograph.
- Disconnect from the network after the page loads. If the tool still finishes the job, the work is local. This is the single most reliable test, and it takes seconds.
A tool that genuinely processes locally will show a burst of requests while the page loads — itself, its scripts, its icons, possibly a model file — and then nothing at all when you hand it your document. That silence is the signal.
Where local genuinely stops working
Being honest about the boundary is more useful than pretending there is not one. A browser tab cannot do everything.
- Very large files. A 400-megabyte video will exhaust the memory a tab is allowed, and the tab will be killed. Some work belongs on a machine with more headroom.
- Large language models. A model capable of writing a competent summary does not fit in the memory a tab can claim, at least not yet, at least not on a phone.
- Work that has to happen while you are away. If the result must be waiting for you in the morning, something has to keep running after you close the lid.
- Coordination between people. Local processing is between you and your device. Showing a colleague the same document requires a shared place to put it.
These are real, and any tool that claims otherwise is overselling. The correct reading is that local is the right default for a broad, boring, high-volume category of work — and the wrong tool for a narrow set of genuinely heavy jobs.
So why do so many sites still upload?
Not because the work requires it. Four other reasons account for most of it.
The first is that server-side code is easier to write and easier to debug. You control the runtime, you can use any library, and you do not have to care about browser differences. Local-only code means shipping megabytes of WebAssembly and testing across devices.
The second is cost accounting. Bandwidth for an uploaded file is cheap and predictable; compute in the user's browser is free to the operator but expensive in engineering time. The incentives point at the server even when the technology does not require it.
The third is that an upload creates a record. A file sitting in storage is a tenant, an account, a reason to come back, and a data asset. That is a business model, not a technical necessity.
The fourth is habit. Most tool sites are assembled from the same handful of templates and the same list of ideas, and the template uploads.
None of these are sinister by themselves. But they explain why "it works in your browser" is worth checking rather than assuming, in either direction.
A rule you can apply
Match the sensitivity of the file to the architecture, and stop worrying about the rest.
- Documents with personal data — identity scans, contracts, medical or financial records — should go to tools that work locally. The cost of the mistake is not worth the convenience saved.
- Ordinary work product — a product photo, a resized banner, a formatted log file, a converted data table — is fine either way, so choose on quality and speed.
- Anything requiring a large model will be sent somewhere no matter which site you use. In that case the useful question shifts from "is it uploaded" to "what happens to it afterwards, and for how long".
If you want to see the difference directly, try it on something disposable. Run a picture through the image compressor with the network disconnected, merge two pages in the PDF toolkit while offline, and format a blob of JSON in the JSON formatter with the Wi-Fi switched off. All three will finish. That is the entire argument, demonstrated in about a minute, and it is a better test than any sentence on a page like this one.