How local file processing in a browser works
If nothing is uploaded, what is actually doing the work — and where?
What "local" means here
A conventional online converter is a website with an upload endpoint. Your file is transmitted to a machine you do not control, processed there, stored for some period, and offered back as a download. Local processing removes the middle of that sentence: the code that reads your file runs inside the browser tab you already have open, on your own processor, and the result is written back to your own disk.
The site is still fetched over the network — HTML, stylesheets, scripts and WebAssembly modules all arrive from a server, like any web page. The distinction is direction. Program code comes down; your file does not go up.
The browser already contains the parts
| Feature | What it provides |
|---|---|
| File and Blob APIs | Read the bytes of a file the user selected or dropped, without a form submission |
| Web Workers | Run heavy work on a background thread so the interface keeps responding |
| WebAssembly | Run compiled C, C++ or Rust codec libraries at close to native speed |
| Canvas and OffscreenCanvas | Decode, draw, resize and re-encode images |
| WebCodecs | Reach the browser's own hardware-accelerated video encoders and decoders |
| WebGPU | Run model inference and parallel pixel work on the graphics processor |
| File System Access | Write the result straight to a location the user picks, where supported |
None of this is exotic. It is the same platform that runs spreadsheets, design tools and games in a tab. The only unusual decision is refusing to add a server to it.
The path a file takes
- You choose a file. The browser hands the page a handle to it — not a copy, a reference.
- The page reads the first bytes to identify the real file type from its signature, rather than trusting the extension.
- It estimates how much memory the job needs, and refuses or queues the work if that exceeds what the device can safely provide.
- The bytes are transferred into a Web Worker. Transferring an ArrayBuffer moves ownership rather than copying it, so a large file does not exist twice in memory.
- Inside the worker, a WebAssembly codec or a platform API does the actual decoding and encoding.
- The result comes back as bytes, is wrapped in a Blob, and is offered to you as a download or written to a location you choose.
- The temporary URL for that Blob is revoked and the buffers are released.
Why WebAssembly is the part that changed
Image and video codecs are decades of carefully optimised C. Rewriting them in JavaScript was never realistic. WebAssembly is a portable binary instruction format that browsers execute in a sandbox at speed close to native code, which means those existing libraries can be compiled and shipped to the browser as they are.
The sandbox matters as much as the speed. A WebAssembly module has no ambient access to your file system, your network or your other tabs. It sees the memory the page hands it and nothing else. A malicious or simply buggy codec cannot wander off and read something it was not given.
What still touches the network, and why it is not your file
Three things arrive over the network: the page itself, the engine for the tool you opened, and — for background removal — the model weights. All three are FileSlimmer's own static assets, fetched from FileSlimmer's own origin before any of your bytes are read. They are downloads, they are cacheable, and after the first use they can be served from the browser's own cache with no network at all.
Everything after that point is local. The engines receive file bytes only through postMessage from the page; they are never given a URL to send anything to, and a content security policy restricts where the page could connect even if some code tried.
The trade-offs, stated plainly
| Consideration | In your browser | On a server |
|---|---|---|
| Where your file goes | Nowhere | To a machine you do not control |
| Speed | Whatever your device can do | Whatever the operator paid for |
| Very large files | Bounded by browser memory | Bounded by the operator's limits |
| Works offline | Once the engine is cached, yes | No |
| Exotic formats | Only what compiles to WebAssembly | Anything the operator installs |
| Batch of a thousand files | Constrained by the device | Usually better suited |
Local processing is not universally better. It is better when the file is private, when the device is capable, and when the work fits in memory. A server is better when you need to process far more than one machine can hold. Being clear about which situation you are in is more useful than insisting one approach wins everywhere.
What this does not claim
This is a statement about what this application does. It is not a claim about your browser extensions, which can read the contents of any page you open, nor about your operating system, which can inspect any file you touch, nor about your network operator, which can see that you visited a site. Those are outside the reach of any website, and a tool that tells you otherwise is overstating its case.
The claim is narrow and checkable: your selected files are processed locally in this browser and are not uploaded by FileSlimmer. The next guide explains how to verify it yourself instead of believing it.
Tools for this
Sources
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs