The moment before you click Upload
You know the moment. The portal wants the PDF under 2 MB. The scan of your passport is 7 MB. It is 11:40 pm and the deadline is midnight. You type “compress pdf online”, click the first result, and a cheerful dropzone invites you to drag the file in.
Then a small voice asks: where is this going?
That hesitation is well placed. The questions people type into search — are online PDF converters safe, is it safe to compress images online — are really one question: once my file is on someone else’s computer, what happens to it? This article answers that honestly, explains the alternative that has quietly matured inside every modern browser, and gives you a checklist you can run on any tool, including ours.
What actually happens when you upload a file to a typical converter
Strip away the branding and most free online converters share one architecture: the browser is a thin form, and the real work happens on a server. That is not sinister in itself — it is how the web worked for twenty years — but it has consequences that are worth spelling out step by step.
- Transfer. A complete copy of your file travels to a machine you do not control. For a signed contract or a medical report, that copy is as sensitive as the original.
- Storage. The file is written to disk — or to a cloud bucket — so a worker process can open it. At this point it exists in at least two places, often three once backups run.
- Processing. A program opens it. If that program has a parsing vulnerability (PDF and image libraries have a long history of them), your file is now inside a system that may itself be compromised.
- Retention. Policies typically promise deletion “within 1 hour”, “after 24 hours” or “when you close the page”. These are promises, not mechanisms you can inspect. Logs, caches, CDN copies and backup snapshots usually have their own, longer clocks.
- Access. Employees, contractors, sub-processors, the hosting provider, and anyone who later breaches any of them can in principle read the file. So can a court order in the operator’s jurisdiction.
- Monetisation. Free services cost money to run. If a converter is not charging you and is not open about how it pays its bills, the file and the data around it — your IP address, the document’s metadata, the fact that you uploaded this — are worth asking about.
None of this requires malice. A perfectly well-intentioned converter still leaves your tax return on a disk in a data centre for a while. The question is not whether the operator is nice; it is whether the design needs them to be.
“Deleted after one hour” describes a cron job, not a guarantee. The only retention policy you can audit is the one where the file never arrives.
The alternative that matured while nobody was watching: client-side processing
Around 2017 the browser stopped being a document viewer and became a credible runtime. Four technologies did most of the work:
- WebAssembly (Wasm) lets code written in C, C++ or Rust run in the browser at near-native speed. That is how FFmpeg, PDF engines, image codecs and even machine-learning runtimes now ship as something a web page can download and execute locally.
- Canvas and WebCodecs give JavaScript direct access to pixels and to the hardware video encoders your laptop or phone already has. Resizing, compressing, cropping and re-encoding media is now a local operation.
- Web Workers move heavy work off the main thread, so a 200-page PDF can be rebuilt without the page freezing.
- The File and File System Access APIs let a page read a file you choose and hand back a result — without that file ever being posted anywhere.
Put together, a “client-side file converter” is a web page that downloads its program once, then does all the work on your device. The file is read from your disk into your browser’s memory, transformed there, and offered back as a download. There is no upload step because there is nothing to upload to.
What “nothing leaves your device” technically means
Your browser runs each tab in a sandbox: a process with no access to your other tabs, your file system beyond the files you explicitly picked, or your camera and microphone without permission. When a client-side tool opens your PDF, the bytes live in that sandboxed process’s memory. When you close the tab, that memory is released. There is no server log that says what the document was, because no server ever saw it.
This is also why such tools keep working if you switch on airplane mode after the page loads — a property you can use to your advantage in a moment.
| Question | Upload-based converter | Client-side converter |
|---|---|---|
| Where does the file go? | To the operator’s server (and its backups) | Nowhere — it stays in your browser tab |
| Who can read it? | Operator, sub-processors, attackers, courts | Only you |
| Retention | Whatever the policy says — unverifiable | Released when the tab closes |
| Works offline? | No | Yes, once the page has loaded |
| Speed | Limited by your upload bandwidth | Limited by your device’s CPU |
| Very large files / heavy AI | Big servers cope | Phones struggle; models must download |
| Can you verify the claim? | Only by trusting the policy | Yes — Network tab, airplane mode |
How to verify a tool yourself in 30 seconds
You do not need to take anyone’s word for any of this — including ours. These checks work on every online utility, and the first two are decisive.
- The Network-tab test. Press F12 (or right-click → Inspect), open the Network tab, clear it, then run the tool on a file. If a
POSTorPUTrequest appears whose size roughly matches your file, it was uploaded. A client-side tool shows only the page’s own scripts loading — and nothing when you process a second file. - The airplane-mode test. Load the tool page, switch your Wi-Fi off, then convert. If it still works, the processing is local. (Some tools lazy-load a library on first use — load the page, run one conversion online, then go offline and run another.)
- The progress-bar tell. A progress bar that climbs at exactly your upload speed, followed by a pause, followed by a download, is the signature of a server round-trip. Local tools are either instant or CPU-bound and scale with file complexity, not file size.
- Read the privacy policy for verbs. Search it for “upload”, “store”, “retain”, “process on our servers” and “third parties”. A client-side tool can say plainly that files never leave your device; an upload-based tool has to describe retention.
- HTTPS is table stakes, not privacy. The padlock means the connection is encrypted. It says nothing about what happens after arrival. Treat it as the minimum, never as the answer.
- Look for a credits or open-source page. Client-side tools are built on inspectable libraries — pdf-lib, FFmpeg.wasm, ONNX Runtime Web, Whisper. A tool that names them is telling you how it works; one that names nothing is asking for trust.
- Be suspicious of “AI enhance” on a free tool. Removing backgrounds or transcribing speech can run on-device with small models, but many services quietly ship your file to a cloud API. If the feature works offline, it is local; if it needs a sign-up, assume it is not.
Where client-side tools honestly fall short
It would be easy to end there, but a one-sided argument is a weak one. Local processing has real limits, and you should know them before you rely on it.
- Your device does the work. A 4 GB video re-encode that a data centre shrugs at can take a mid-range phone a long time, and memory limits in mobile browsers are real. Good tools say so and cap file sizes rather than silently failing.
- AI models have to download first. On-device speech-to-text or background removal means fetching a model — anywhere from 40 MB to several hundred — before the first run. Once cached it is fast and private; the first visit is not instant.
- Some jobs genuinely need the internet. Fetching another website’s metadata, checking redirects or pulling a favicon cannot happen without a request leaving your browser. The honest pattern is to do only that part remotely and say so on the page.
- “Client-side” is not a magic word. A page can process locally and send analytics about what you did, or load scripts from a dozen trackers. Processing privacy and tracking privacy are separate questions — check both.
Where we stand
We built Toolity on one rule: a file you choose never leaves your browser tab. PDFs are rebuilt with pdf-lib and PDF.js, images and video are processed with Canvas, WebCodecs and MediaRecorder, archives with JSZip, and the AI features — transcription with Whisper, background removal with MODNet and BiRefNet — run small open models on your device through Transformers.js and ONNX Runtime Web. The handful of tools that need the internet by definition (URL inspectors such as the redirect checker and Open Graph preview) fetch only the public page you typed, via public read-only relays, and say so on their own pages. We use anonymous page-view analytics to know which tools people use; it never sees your files. Every library we depend on is listed on the credits page, and the full policy is on the privacy page. Run the Network-tab test on us whenever you like.
Seven everyday jobs that should never involve an upload
The abstract argument becomes obvious the moment you picture the actual file. Each of these is a routine task people search for every day; each involves a document you would not hand to a stranger.
The pattern is the same every time: the task is mechanical, the document is personal, and there is no technical reason the two should meet on someone else’s server.
Why this is the direction the web is heading
Three forces push the same way. Regulation — GDPR, India’s DPDP Act, CCPA — makes holding other people’s documents a liability, so the cheapest compliant server is the one that never receives the file. Hardware keeps improving faster than connections do; the phone in your pocket can re-encode video in real time, while uploading that video is still the slow part. And the platform itself keeps growing: WebGPU brings real machine-learning acceleration to the browser, and WebCodecs and the File System Access API remove the last excuses for a round-trip.
The upload-based converter is not going away tomorrow — some jobs still need big machines — but it is no longer the default architecture, only the familiar one. The next time a dropzone invites you to drag a file in, you now know which question to ask, and how to check the answer in thirty seconds.
Frequently asked questions
Are online PDF converters safe to use for sensitive documents?
It depends entirely on where the processing happens. Upload-based converters receive a full copy of your PDF, so you are trusting their retention policy, their security and every third party they use. Client-side converters open and rebuild the PDF inside your browser tab, so the file never leaves your device — the only architecture that removes the risk rather than managing it.
Is it safe to compress images online?
Compressing a photo is pure arithmetic the browser can do itself with the Canvas and WebCodecs APIs, so there is no technical reason for an image compressor to upload anything. If a tool does upload, your photo — including its GPS and camera metadata — sits on someone else’s disk for as long as their policy says. Prefer tools that process in the browser and verify it with the Network-tab test above.
How can I tell whether a tool uploads my file?
Open developer tools (F12), switch to the Network tab, clear it, then run the tool. A POST or PUT request about the size of your file means it was uploaded. For a second opinion, switch on airplane mode after the page has loaded: a true client-side tool keeps working offline.
What is a client-side file converter?
A web tool whose conversion code runs in your browser — JavaScript plus WebAssembly ports of libraries such as pdf-lib, FFmpeg or ONNX models — reading the file from your disk, processing it in memory and handing back a download, with no server involved after the page itself has loaded.
Does HTTPS mean an online converter is private?
No. HTTPS protects the file in transit. Once it arrives, the operator can read, store, scan or share it. Privacy depends on whether the file is sent at all, not on how well it is encrypted on the way.
Are there things client-side tools cannot do?
Yes. Jobs that need data from the internet (another website’s page, live exchange rates), very large machine-learning models, or collaboration between people need a server for at least part of the work. Honest tools say which features do, and keep the rest on-device.
Kapil Pidhwani