Most free online file tools follow the same pattern. You drop a file, the page sends it to a server, the server does the work, and the result comes back. The pattern is convenient and it is also a privacy risk – the file leaves your machine and lands somewhere whose logging and retention policies you have to trust without much way to verify them.
A smaller category of tools does the work directly in the browser, using WebAssembly to run the same processing libraries locally that a server would. The file never moves. Below are five of them, picked because they cover different file categories and because they are actually browser-based, not just marketed as private.
1. Squoosh (Google)
Squoosh is the canonical demo of in-browser image compression. The Chrome team built it in 2018 partly as a real tool and partly to showcase WebAssembly. You drop a JPG, PNG, WebP, or AVIF in, pick a target format and quality, and the encoded file appears with a side-by-side preview against the original. Slider controls let you compare quality settings live.
Under the hood it ships MozJPEG, OxiPNG, libwebp, libavif and a few smaller codecs as WebAssembly modules. Open the browser’s network panel while you compress something – you will see the page load and the codec download, then no traffic at all while the file is processed. Even the comparison preview runs entirely in the local image decoder.
What it is good for: one-off image compression, comparing codecs visually, learning how compression settings affect file size. Less useful when you need to process batches or convert between many formats with different presets.
2. PDF.js (Mozilla)
PDF.js renders PDF files directly in the browser. The library has been a quiet workhorse since 2011 – it is what Firefox uses internally to show PDFs, and it is also embedded in countless third-party tools. More recently, editing and form-filling capabilities have been added on top, written substantially in WebAssembly for the text-layout work.
If you need to view a PDF without it touching a server, drop it into any tool built on PDF.js (most browser-based PDF viewers are). Suites like Convertilo build broader browser-based file tools on top of PDF.js for splitting, merging, rotating, and converting PDFs – all of it running locally, with the network tab confirming that no upload takes place. The same engine handles annotations and form fields in-browser.
What it is good for: viewing, splitting, merging, and converting PDFs without sending them anywhere. Especially relevant for documents like contracts, scanned IDs, or internal corporate files that would be a problem to hand to an unknown server.
3. FFmpeg.wasm
FFmpeg is the most widely used video and audio toolchain in the world. The .wasm port, which became production-ready around 2022, lets the same toolchain run inside a browser page. It supports the same command-line flags as native FFmpeg, which means existing transcoding recipes work without modification.
The WebAssembly module is large – around 30 MB on first download – and the performance is two to three times slower than native FFmpeg on the same machine. Both numbers are improving with each release as browsers add SIMD and multi-threading support. For one-off video trimming, format conversion, or audio extraction, FFmpeg.wasm is now a practical option, and several browser-based video editors are built on it.
What it is good for: occasional video conversion or trimming when you do not want to upload a 4K file to a stranger’s server. Less suitable for high-volume production work where native FFmpeg in a server pipeline remains the right tool.
4. Tesseract.js
Tesseract is Google’s open-source OCR engine. Tesseract.js wraps it in WebAssembly so that text extraction from images and scanned PDFs can run in the browser. It supports over a hundred languages, each with its own model file.
The model files are sizeable (each language adds a few megabytes), but once downloaded they cache. Drop a scanned document in, the page processes it locally, the recognized text appears. No image is ever uploaded. This is particularly relevant for scanning ID cards, contracts, or any document whose text content is sensitive enough that you would not paste a photo of it into Google Drive or a third-party OCR service.
What it is good for: occasional OCR on documents you would rather not hand to a cloud OCR service. Works well for printed text in good lighting; struggles with handwriting and unusual fonts.
5. Bitwarden Send
The first four tools are browser-based file processors. Bitwarden Send is included here as a different category – encrypted file transfer rather than file processing – but it shares the underlying principle: the work that should stay private stays private.
Bitwarden Send encrypts a file in your browser, uploads only the ciphertext, and gives you a link that includes the decryption key in its URL fragment. The fragment never leaves the recipient’s browser before decryption, so Bitwarden’s servers cannot decrypt the file even if compelled by a legal order. The end-to-end model is technically robust and has been audited multiple times.
What it is good for: sending a sensitive file to someone without trusting the intermediary. The recipient does not need an account, just the link.
How to Verify Any of These Yourself
Marketing language is cheap. The actual test for whether a tool is privacy-first is two minutes of work in the browser’s developer tools.
Open the Network panel before dropping your file in. Drop the file. Watch what happens. If the page only loads its own assets and the relevant WebAssembly module, and shows zero network activity during the actual processing, the tool is genuinely browser-based. If there are POST requests to the tool’s backend while your file is being processed, the marketing is misleading you and the file is being uploaded.
The test takes longer to describe than to perform. Two minutes, and you know. Any tool that claims to be privacy-first but fails this check should not be trusted with anything you would not also paste into a public forum.
Why Any of This Matters
The underlying technology shift here is not new. WebAssembly has been a finalized standard since 2017, and the codec ports have been production-ready for years. What is changing is the tooling around them – tools genuinely built on the no-upload principle, rather than retrofits of older server-based architectures. Choosing one of these tools for sensitive work is the simplest single step you can take to reduce the surface area of “where my files have been” in a given week