How it works
Every tool on this site is an ordinary web page plus an open-source neural network that runs inside your browser. This page explains what happens from the moment you open a tool, how fast it is on real hardware, and how to check for yourself that your files aren't uploaded.
What happens when you open a tool
- The page loads. It's plain static HTML, CSS and JavaScript, with no server-side code and no login.
- The model downloads, once. The page fetches the model weights, an ONNX file of roughly 5 MB to 600 MB depending on the tool, from
models.swordfishsoft.org. A progress bar shows real bytes received. The browser saves the file in its Cache Storage. - An engine is picked. If your browser supports WebGPU and the tool has been validated on it, the model runs on your graphics card. Otherwise it runs on the CPU through WebAssembly, on a single thread. The tool shows which one it's using.
- Your file is read locally. When you drop in an image, recording or document, the browser reads it straight from disk into the page's memory. The model runs in a background thread (a Web Worker) so the page stays responsive.
- The result is built in the page. The PNG, audio file or text you download is created in the browser and saved as a local download. It never passes through a server.
On your next visit the model comes out of the browser cache instead of the network, so the tool is usually ready in one to three seconds.
Check it yourself
You don't have to take our word for it. In Chrome, Edge or Firefox:
- Open a tool and wait until the model has finished loading.
- Open the developer tools (F12, or ⌥ ⌘ I on a Mac) and switch to the Network tab. Click the clear button so the list is empty.
- Process a file.
- Look at the list. You'll see no request carrying your file. Your data never appears in a request body, and nothing is sent that's anywhere near the size of your file.
A stricter test: once the model has loaded, turn off Wi-Fi or unplug the network cable, then process another file in the same tab. It still works, because nothing in the processing needs the network.
WebGPU or WebAssembly: measured speeds
Every tool has to pass the same test before release. Its built-in sample goes through the WebGPU path and the WebAssembly (CPU) path in an automated Chrome session, and we check the output as well as the timing. These are the processing times from those runs, on an Apple M2 Max, with the model already loaded. The CPU column was re-measured on 2026-09-25 after the change described below, so it is single-threaded:
| Tool | Sample input | WebGPU | CPU (WASM) | Download |
|---|---|---|---|---|
| Transcribe audio | 30-second podcast clip | 2.0 s | 12.9 s | 291 / 206 MB |
| Text to speech | 207 characters → 13 s of speech | 1.3 s | 19.2 s | 326 / 305 MB |
| Remove background | 1024 × 683 photo | 1.2 s | 5.3 s | 98 / 192 MB |
| Remove objects | 1024 × 683 photo | 0.34 s | 11.2 s | 107 / 62 MB |
| Depth map | 1280 × 855 photo | 0.28 s | 5.5 s | 99 / 27 MB |
| Upscale 4× | 512 × 384 → 2048 × 1536 | 1.0 s | 11.8 s | 5 MB |
| Unblur image | 1024 × 768 photo | 2.0 s | 39.3 s | 275 MB |
| Vocal remover | 20-second song | 2.1 s | 74.2 s | 67 MB |
| Image to text (OCR) | Receipt, 20 lines | 0.42 s | 3.0 s | 17 MB |
| Redact personal info | 209-word support email | 0.32 s | 2.8 s | 596 MB |
| Colorize photo | 923 × 737 photo | — | 5.8 s | 135 MB |
| Passport photo maker | 960 × 1150 portrait → 600 × 600 | 0.19 s | 1.5 s | 26 / 13 MB |
| Describe an image | 1024 × 635 photo → 3 pieces of text | 6.8 s | 14.1 s | 194 / 251 MB |
| AI music detector | 3-minute song (MP3) | — | 0.48 s | 15 KB |
Where two download sizes are listed, the WebGPU and CPU paths use different versions of the model. Precision that suits a graphics card isn't always the best choice for a CPU, so each path gets whichever version we measured as better on it. A slower laptop will take longer than the numbers above, and a phone longer still. Tools marked Desktop recommended on the home page use models too large to count on a phone handling.
Why the colorizer has no WebGPU column
Some models run correctly on one engine and not on the other. The colorizer we use fails to start on WebGPU in current browsers, so it's declared CPU-only and never tries the GPU. We've also seen models on WebGPU that return a plain black image with no error at all. That's why every tool's output is checked, not just its speed, and why some tools check their own output while running and retry on a safer setting.
Why the first load is the slow part
Processing takes seconds, but the model is the largest download on the page. On a typical home connection, a 100 MB model takes somewhere between a few seconds and half a minute. After that it's cached, so the wait only happens once per browser. Clearing your browser's site data for swordfishsoft.org removes the cached models if you want the disk space back.
Why the CPU path uses one thread
WebAssembly can only spread work across several CPU cores when a page is "cross-origin isolated", which a site turns on with two HTTP headers (Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy). Those headers also stop the page from embedding frames from other sites, and that includes the ad frames that pay for keeping these tools free. We chose the ads, so since 25 September 2026 the pages no longer send the headers. The WebGPU path is unaffected. The CPU path now runs on one thread, which on our test machine made it about three times slower than before. The table above shows the new numbers.
What does leave your browser
To be complete, these are the network requests that do happen:
- Requests for the page itself and for the model files, which our hosting provider (Cloudflare) logs like any web server does.
- A cookie-free page-view beacon from Cloudflare Web Analytics.
- Once ads are enabled, the requests an ad network makes to show them. See the privacy policy.
None of these include your files, the text you type into a tool, or the results.