Browser-based file tools do the work inside the page instead of on a server. Your file is read from disk by the File API, processed by a WebAssembly engine such as qpdf or FFmpeg running in the tab, and written back as a download. No upload step exists, so nothing is sent.
The architecture has three parts. The File and Blob APIs move bytes between your disk and the page without a network round trip. WebAssembly runs engines that were originally written for the desktop, which is why the results match a desktop tool rather than a simplified web approximation. Canvas, Web Workers and MediaRecorder cover the jobs that need drawing, background processing or a camera. The trade is that the first run downloads the engine, and everything has to fit in the memory of one tab.
Most people meet this idea in a privacy line on a tool page: files never leave your device. That sentence is either true or it is not, and it is decided by architecture rather than by intent. This guide explains what a browser can actually run today, why the upload step disappears when you build this way, and the costs that come with it.
Image Compressor
A concrete example. Canvas and OxiPNG run in the tab, the before and after sizes are shown side by side, and the file is never uploaded.
Two architectures: the server round trip and the local tab
Most online converters follow the same shape. Your browser sends the file to a server with an HTTP upload, the server runs a tool such as ImageMagick or a headless FFmpeg, and a download link comes back. The work is real and often fast, but the file has to leave your machine for it to happen, and it stays on that machine for as long as the operator keeps it.
A browser-based tool keeps the same steps and drops the server. Reading the file, running the engine and writing the result all happen in the tab. That is not a small variation on the upload model. It removes a whole class of problems, because there is no transfer to intercept, no queue to wait in and no retention window to read.
| Step | Server-based tool | Browser-based tool |
|---|---|---|
| Reading the file | Copied into their storage | Read by the File API, stays local |
| Processing | Their CPU, usually queued | Your CPU, inside the tab |
| Result | A download link that expires | A Blob download, ready immediately |
| Who can read the file | Anyone with access to their storage | Only you |
What the browser actually runs
A short tour of the stack, because these capabilities are what make the privacy claim possible rather than a marketing layer bolted on top.
WebAssembly brings desktop engines to the tab
WebAssembly is a compact binary format that runs at close to native speed inside a sandboxed virtual machine. Engines written in C, C++ or Rust are compiled to it and shipped as ordinary files: qpdf for PDF encryption, FFmpeg for video and audio, Tesseract for optical character recognition, pdf-lib for building and editing PDFs, and OxiPNG for lossless PNG optimization. PDF.js handles PDF rendering and text extraction. Because these are the same engines used on the desktop, the output is not a web approximation: a video encoded by the FFmpeg build in your tab is the output of FFmpeg.
Canvas and the image pipeline
Images are the one category that does not need WebAssembly. The Canvas API exposes the same drawing surface a native image editor uses. createImageBitmap decodes a file, a canvas holds the pixels, and toBlob encodes the result back to PNG, JPEG, WebP or AVIF. Cropping, resizing, watermarking and format conversion are all pixel operations on that surface. The Image Compressor pairs it with OxiPNG for PNG output, which re-compresses the file losslessly instead of throwing quality away.
Web Workers keep the interface alive
Heavy work on the main thread freezes the page, so the long jobs run in a Web Worker, a background thread with no access to the DOM. The video tools hand work to FFmpeg inside a worker and receive log lines and progress events back, which is why the progress bar keeps moving while the encoder is busy. Tesseract follows the same pattern. Notably, the OCR setup here uses a single-threaded engine build, so it does not need the SharedArrayBuffer headers that many WebAssembly tools require from the server.
File and Blob move the bytes
The File API is what replaces the upload. When you drop a file on the page, JavaScript receives a File object, and file.arrayBuffer() reads its bytes into memory on demand. The result is a Blob, which can become a temporary local URL or be handed straight to a download. The bytes travel from disk to memory and back, and there is no code path in that loop that talks to a network. This is also why a browser tool has no upload size limit imposed by a server, only the memory limit of the device.
Why local processing means nothing gets uploaded
The claim is easy to state and easy to verify. Uploading is a network request that carries your file, and a browser tool never makes one, because there is nothing on the other end that needs it. The only requests a page like this makes are for its own code and assets: the HTML, the stylesheet, the engine on first use and the font.
You do not have to take that on faith. Open the browser developer tools, switch to the network panel, clear it, then process a file and watch. The requests that appear carry code and assets. None of them carry your document, and if you disconnect from the network after the engine has loaded, the processing still works. There is a longer, step-by-step guide to checking whether a tool uploads your file if you want the full procedure.
| Request you will see | What it carries |
|---|---|
| The page, its CSS and its JavaScript | Site code, not your file |
| The engine, on first use | A compiled tool, cached afterwards |
| Web fonts | A typeface |
| Analytics script | A page view, not file bytes |
The last row matters because it is the usual source of false alarms. Analytics load on the page and report that a page was viewed, not the contents of your document. This site itself loads Google Tag Manager, which is why the network panel shows a script from Google. That request reports a page view, and it is not a file transfer.
What you pay for it
Local processing is not free, and the honest version of the case is worth stating plainly. Three costs show up, and a fourth point explains where the browser stops.
- First run downloads. Each engine is fetched once: about 30 MB for the FFmpeg core behind the video and audio tools, about 6.7 MB for the OCR engine and English data, about 1.3 MB for the PDF engine, and about 1.4 MB for the PDF.js worker used for page previews. None of it is your file, and all of it is cached, but a cold start on a slow connection is a slow start.
- Memory is the ceiling. Everything the engine reads and writes lives in one tab. A desktop tool streams a large file from disk, while a browser tab holds it, so an enormous video or PDF can exhaust memory before it finishes. Some tools state a hard cap for this reason, such as the 50 MB limit on the PDF unlock tool.
- A server can be faster. Video encoding is CPU-bound, and a dedicated machine with more cores and a warmer cache will beat a laptop tab. The browser build also relies on software encoding rather than a hardware encoder, so it does not get the GPU speedup a native build can use.
- Some jobs still need a server. Background removal, object erasing and generative image enhancement depend on large models that no reasonable download budget covers. Those three are handled by Cloud AI and they do upload the image. Everything else on the site is local.
For a document of a few megabytes or a clip of a minute, none of these costs are felt, and the trade buys privacy and the absence of quotas. For a two-hour 4K recording, a desktop tool or a server job is the better choice, and the honest answer is to say so.
The same pattern across the tool set
The homepage groups the tools into five sections, and the architecture is the same in each. PDF work runs on qpdf, pdf-lib and PDF.js. For example Merge PDF combines files with pdf-lib, while PDF to Text extracts text with PDF.js and falls back to Tesseract only for scanned pages. Image work runs on Canvas and OxiPNG. Video and audio run on FFmpeg, with Video Compressor and the audio tools sharing a single engine. OCR runs on Tesseract. The three Cloud AI tools are the exception, and the site labels them as such rather than blurring the line.
The practical upshot is that you can reason about any tool the same way. If it names a real engine and runs it in the tab, the file stays put. If it needs a larger model than a browser can download, it will say that it uploads, and it should say it on the page rather than in a footnote.