Guide

How Browser-Based File Conversion Keeps Your Files Private

Online converters mainly follow one of two architectures, and the difference decides who gets a readable copy of your file. Here is how to tell them apart — and how to verify the answer in about a minute.

Two ways a converter can work

Online file converters mainly follow one of two architectures, and the difference determines who has access to your file.

In the server-side model, your file is transmitted to a computer belonging to whoever runs the site. That machine does the conversion and sends a result back. This is how most free converters work, and it is not sinister — it is simply the older and more capable approach.

In the client-side model, the page sends you a program instead of you sending it a file. Your browser runs that program locally, reads the file from your disk, does the work using your device's own processor and memory, and hands you the result. The file never becomes a network request.

Both can be described as "converting online". Only one involves your document leaving your machine. Some services also mix the two — handling simple jobs locally and sending anything heavier to a server — so the reliable answer for any given tool is to check rather than assume, which the section below shows how to do.

What actually happens on a server-side converter

It is worth being concrete rather than alarmist, because the risks are specific and mostly mundane.

Your upload is almost certainly encrypted in transit — the padlock in the address bar means the connection is protected while data is moving. What it does not tell you is anything about what happens after arrival. At the server, the file is decrypted so it can be worked on. At that moment it exists in readable form on a computer you do not control.

From there, reasonable questions have no visible answers:

How long is it kept? Many services state a deletion window. You cannot verify it.
Where is it stored? Files often land in cloud storage in a jurisdiction with different legal protections from yours.
Who else is involved? Hosting providers, storage providers, and error-monitoring services may all touch the infrastructure.
What is logged? Filenames alone can be revealing — redundancy-letter-final.pdf tells a story before anyone opens it.
What happens if the company is breached, sold, or shut down? Retention promises are policies, not mechanisms.

For a holiday photo, none of this matters. For a payslip, a medical letter, an unsigned contract, or a client's data that you are contractually responsible for, the calculation is different — and often the deciding factor is not what the service does with the file but that you cannot demonstrate what it did.

What the browser can do instead

Doing real file work in a browser tab is relatively recent. Three capabilities made it practical.

Reading local files. The File API lets a page read a file the user explicitly chooses or drops onto it, into the tab's memory. The page cannot browse your disk or take a file you did not hand it.

Working with raw bytes. Typed arrays give JavaScript efficient access to binary data, which is what image and document formats are made of. Before them, byte-level work in a browser was impractically slow.

Real processing power. The canvas element can decode an image, expose its pixels, and re-encode it in another format using the browser's own built-in image encoders — the same ones the browser uses everywhere else. For heavier work, WebAssembly allows libraries originally written in other languages to run in the tab at close to native speed.

Put together, these mean a page can be delivered once and then do genuine work with no further conversation with any server. The Workbench tools use exactly this: the Image Converter works through the canvas encoders, and the two PDF tools use a JavaScript PDF library running in the page.

How to verify the claim yourself

Any site can put "your files never leave your device" in its footer. The useful thing about client-side processing is that the claim is checkable in about a minute, using tools already in your browser. You do not have to take anyone's word for it — including ours.

The network check

Open the converter page.
Press F12 (or Cmd+Option+I on a Mac) to open developer tools, and select the Network tab.
Clear the list, then add your file and run the conversion.
Watch what appears. A client-side tool produces no new request carrying your file. A server-side tool produces an upload — typically a POST whose size roughly matches your file.

Sorting the request list by size makes this obvious: an uploaded file is usually the largest entry by a wide margin.

The offline check

Simpler and harder to misread. Load the page, then disconnect from the internet — switch off Wi-Fi, or tick "Offline" in the Network tab. Now run a conversion. If it completes, the work happened on your machine, because there was nothing else it could have happened on.

This works on the Workbench tools once the page has finished loading. It is a quick, convincing demonstration that the processing can happen on your device. It is not complete proof on its own: a page could behave differently while it is online, for example by sending data once the connection returns. The network check above is the direct way to see what is actually sent while you work, and the two tests are strongest together.

What client-side processing does not protect you from

Being straightforward about the boundaries is more useful than overselling the model.

It is not a guarantee about the page's intentions. A page that runs code on your device could, in principle, send data somewhere. That is precisely why the verification steps above matter — the architecture makes the claim testable, which is different from making it self-evidently true.
It does not protect against your own device. Browser extensions can read page content. Malware sees anything you see. A shared or compromised computer is a risk no web page can address.
It does not protect the output. Once you save the converted file, ordinary handling applies — where you store it, who you email it to, what your backup does with it.
It does not remove information inside the file. A PDF still contains whatever it contained. A photograph may still carry EXIF metadata including GPS coordinates, depending on the operation performed.
It does not hide that you visited. Loading any page involves a request to a web server, which sees your IP address. What it does not see is your file.

The honest summary: client-side processing removes one specific and significant risk — your document sitting in readable form on someone else's computer. It does not make the file anonymous, sanitised, or immune to everything else. It is one property, worth having, with clear edges.

The trade-offs you accept

Local processing is not free. Choosing it means giving up several things a server can offer.

Your device sets the ceiling. A server has predictable memory; your phone does not. Browsers cap how much memory a tab may use, and a large job can fail or cause the tab to reload. This is why claims of "unlimited file sizes" from any browser-based tool should be read as "no limit we impose", which is a different statement.

Heavy processing is often out of reach. Optical character recognition, video transcoding, and sophisticated document analysis are possible in a browser but demanding. Workbench does not offer them. The tools convert and resize images, assemble images into PDF pages, and combine, extract, reorder, and rotate PDF pages. None of them perform OCR, PDF compression, redaction, or image editing beyond resizing.

Results are not stored for you. Nothing is saved on a server, which means nothing can be retrieved after you close the tab. If you did not download the result, it is gone.

Your browser's capabilities matter. Which formats can be produced depends partly on your browser and version, so results are less uniform than a server that runs the same software for everyone.

Where Workbench stands, precisely

Your files are read into the browser tab and processed there. They are not uploaded, queued, or stored on any Workbench server, and there is no account system.

Two things the pages do fetch from the network are worth naming, because "nothing leaves your device" is easily overstated: web fonts load from Google Fonts, and the pages load their own stylesheet and, for the PDF tools, the open-source pdf-lib and PDF.js libraries from this site. These are requests for the page's own code and styling. None of them carries your file. And, as with any website, the hosting provider can log ordinary technical information such as your IP address — the privacy policy sets out what is and is not collected.

If the distinction matters for your work, run the offline test. It takes a minute and it answers the question directly.

Takeaway

"Online converter" covers two very different architectures, and some services mix them. One uploads your file; the other sends you a program.
Encryption in transit says nothing about what happens to a file after it arrives on a server.
You can verify a client-side claim yourself with the Network tab, or by loading the page and going offline.
Local processing removes one clear risk. It does not sanitise files, protect your device, or secure the output.
The cost is real: your device's memory is the limit, and heavy features like OCR are simply not on offer.