Article
What is client-side processing?
Most file tools work by sending your document to a remote computer, which does the heavy lifting and sends a result back. Client-side processing flips that: your own browser does the work, and your file never leaves your device.
Two ways a tool can work: your machine or theirs
With server-side processing, uploading a file is a bit like dropping off laundry: you hand it over, a remote machine handles it, and you collect the result later. Client-side processing is more like doing the laundry at home. The tool runs inside your browser tab, reads the file from memory, processes it, and hands you the output, all without the file touching any network connection. The website only needs to deliver the processing code once. After that, it works entirely on your end.
What WebAssembly brought to the browser
For years, browsers could only run JavaScript, which is fine for interfaces but too slow for tasks like re-encoding a video or applying compression to a large image. WebAssembly (usually shortened to WASM) changed that. It is a compact binary format that browsers can execute at near-native speed, so code originally written in C or C++ can be compiled to WASM and run inside a browser tab without any plugin. The same codecs and compression libraries that power desktop software now run directly in the page. JavaScript and WebAssembly work together: JavaScript handles the interface and the orchestration, while WASM handles the number-crunching.
What actually happens during a job
When you drop a file onto a client-side tool, the page loads a small processing engine (often a WASM module) if it has not already done so, then passes your file to it through JavaScript. The actual processing usually runs on a background thread called a Web Worker, which keeps the browser interface responsive while the work happens. You can open your browser’s Network tab at any point during this, and no request carrying your file will appear. The output is assembled in memory and offered to you as a download.
Honest tradeoffs you should know
The first time you use a tool that relies on a large WASM engine, the browser downloads that engine and caches it. Later uses skip the download and can work fully offline. Because the processing runs on your device, a very large file takes as long as your CPU and available memory allow, and a data centre would finish some heavy tasks faster. What you get in return is real: your file is never transmitted, there is no upload wait on slow connections, and the tool keeps working without internet after that first load.
Tools in this article
Frequently asked questions
Does client-side processing automatically mean my data is private?
Client-side means the file is not sent to a server by design, which is what makes the privacy possible. You can confirm it yourself by opening the Network tab in your browser’s developer tools while processing a file: no outgoing request should carry your file’s data. Even so, it is sensible to check that a tool really behaves this way rather than trusting the label.
Why is the first use of a tool sometimes slower?
The browser needs to download the processing engine (the WASM module) the first time you use it, which can take a few seconds depending on its size and your connection. After that, the engine is cached locally, so later sessions start immediately and the tool works offline.