October 3, 2026 · 8 min read
Browser-Based vs Upload-Based Tools: Pull the Plug and See
How a website edits your file without ever receiving it — canvas, WebAssembly, local AI models — plus the offline dare that proves which kind you are using.
"Nothing is uploaded" reads like marketing. The sane assumption is that it means "uploaded, then deleted, probably". Worth understanding why it can be literally true — because once you know how it works, you can test it, and testing beats believing every time.
The usual way: upload, process, download
A classic online tool is a thin front end bolted to a server. You pick a file, the browser ships the bytes across the network, a program on a machine somewhere does the work, the result comes back. This has real advantages: the server can be enormously powerful, the software can be anything, and a phone from 2017 gets the same output as a workstation.
The cost is structural. A copy of your file now sits on hardware you do not control, for however long their retention policy, their backups and their definition of "temporary" say. Most operators are fine. You cannot tell which ones.
The other way: your browser is the computer
A modern browser is a serious runtime, not a document viewer. The page's code can read a file you choose, rebuild it, and hand you a new one, without a single byte crossing the network. The pieces that make that work:
- The File API. Pick a file and the page gets read access to those bytes, off your own disk. Choosing a file sends nothing anywhere.
- Canvas. Draw an image into a canvas and export it again and you have re-encoded the pixels. That is resizing and quality reduction — and it is why metadata vanishes, because the new file is built from pixels, not copied from the old one.
- WebAssembly. Real compiled programs running in the tab at near-native speed. This is how ffmpeg — the engine behind most video processing anywhere — re-encodes video inside a browser.
- ONNX Runtime and friends. Neural networks download once and run in the tab. That is how background removal works with no server: the model does its inference on your device.
- Blob URLs. The finished file is handed to you as a locally generated download. No round trip, because there was never a trip.
Here is the consequence that matters: the server's only job is to deliver the code. Once the page has loaded, the server is irrelevant to the work. Which is exactly why you can unplug the internet and carry on.
The dare
- Load the page fully. Let any models and WebAssembly bundles finish downloading.
- Disconnect. Wi-fi off, cable out.
- Use the tool on a real file.
- Result? It was computed on your device. A page with no network cannot consult a server.
The developer-tools version is just as decisive. Network tab, clear it, process a file. You will see the page's own assets, maybe a model file, maybe an analytics ping. On a local tool you will not see a request whose payload is the size of your file. Learn that shape once and you can audit any site on the internet in thirty seconds, forever.
What local processing wins, and what it costs
| Browser-based | Upload-based | |
|---|---|---|
| Your file leaves your device | No | Yes |
| Depends on a retention policy | No | Yes |
| Works with the network off | Yes, after loading | No |
| Speed on a big video | Limited by your device | Limited by their server and your upload |
| First load | Heavier — code and models download once | Light |
| Old or low-memory phone | Can struggle or run out of memory | Handles anything |
| Very large files | Awkward; a tab has finite memory | Usually fine |
| Things only a server can do | Impossible | Possible |
That last row is the real boundary, not a get-out. Fetching something from another website, querying a database, running a model too big to download — none of that can happen in your tab, by definition. A tool that has to reach out to the internet on your behalf is a server tool, and good intentions do not change the architecture.
Why your big video is slow, and why that is the trade
Re-encoding video is one of the heaviest things a consumer device ever does. In a tab it runs through WebAssembly on your own processor, single-threaded, with a memory ceiling. A ten-minute 4K clip can take many minutes on a laptop and may run out of memory on an old phone. Nothing was uploaded, so nothing was done by a machine faster than yours. Trim first, pick a sensible resolution, keep the tab in front, use a laptop if you have one.
Run a file through it, then kill your wi-fi and do it again.
Open the File CompressorHow Skrubly is actually built
Five tools are fully local. The metadata cleaner reads and rewrites files in the tab. The compressor uses canvas for images, a PDF library for documents, and ffmpeg compiled to WebAssembly for video. The background remover downloads a small open-source segmentation model hosted here and runs it on your device. The AI text detector and AI image checker analyse what you give them in the tab. For all five: never uploaded, never stored on a server, and still working with the network disconnected.
The TikTok downloader is the exception, and by the logic above it has to be — fetching a video from TikTok is something only a server can do. The link you paste goes to our server, which asks a third-party provider to find a downloadable version, and the video is fetched server-side. What travels is a public URL, not a file of yours.
The site itself behaves like a website: ad-supported, cookies, aggregate analytics, and routine technical data such as IP address, browser and pages visited, as the privacy policy describes. The claim here is specific rather than sweeping. That is what makes it testable.
The same comparison, applied to background removers.
Background removers with no upload