Doesn't running everything in the browser drain my battery?

It uses your CPU instead of someone else's, so yes, slightly more than scrolling Twitter. But a typical PDF compression finishes in a few seconds — the energy cost is dominated by your screen being on, not the compute. For long videos or huge images, the trade-off shifts; we surface progress + a cancel button so you stay in control.

What about huge files my laptop can't handle?

Browsers can address up to a few gigabytes of memory per tab on a modern machine. Beyond that we recommend the desktop build (Tauri), which gets you native file streaming and the ability to chunk through files larger than RAM.

Can I trust that the code really doesn't upload?

Open the Network tab in your browser's DevTools while you use a tool. You'll see the static assets load once, and after that, nothing. The source is also published — you can audit it directly.

What happens if I close the tab mid-process?

The operation cancels; nothing was sent anywhere to begin with. There's no half-uploaded state to clean up. Open the tool again and you start fresh.

Why local-first tools are faster, safer, and more dependable

The two ways a web tool can process your file

When you drop a PDF onto a website, one of two things happens. In the cloud-first model, your browser uploads the file to a server, the server processes it, and the result is downloaded back. In the local-first model, the file never leaves the tab — the same JavaScript engine that renders the page also runs the PDF logic, usually with WebAssembly handling the heavy math.

Both can deliver an identical user experience. What changes is what's true behind the scenes about latency, privacy, and reliability.

Where local-first wins

First, latency. There's no upload time, no round-trip to a region you happen to be far from. A 50 MB PDF takes the same five seconds to read off your disk whether you're in Toronto or Tokyo — and the second pass takes zero seconds, because the file is already in memory.

Second, privacy. A NDA, a tax form, a medical scan — the gold standard for handling sensitive files is to not transmit them. Local-first makes that the default rather than a premium feature.

Third, dependability. Once a local-first tool has been opened once and cached by the service worker, it works offline. Airplane, train tunnel, hotel Wi-Fi with the captive portal in the way — none of that stops you from compressing a PDF.

Where cloud-first still has the edge

Heavy ML inference is the honest counter-example. A 30B-parameter language model isn't fitting in a browser tab in 2026. If your workflow genuinely needs that, a server-side API is currently the right answer.

Same for jobs that legitimately need fan-out across many machines — re-rendering thousands of video frames, training a model, indexing a billion documents. Browsers do one tab at a time, and your laptop has one CPU.

The pragmatic line is: for file-shaped work measured in tens or hundreds of megabytes, local-first is now the better default. For data-shaped work measured in terabytes or for ML measured in dozens of billions of parameters, the cloud is still pulling its weight.

How SnapToolz implements it

Every tool on SnapToolz uses WebAssembly for the parts that need to be fast: pdf-lib and pdf.js for PDFs, browser-image-compression for images, custom WASM for OCR. The page itself is a static export — no runtime server, no edge function — so there's literally no backend to upload to.

Your file is read by the File System Access API or a standard drop handler, passed to a Web Worker so the main thread stays responsive, processed in memory, and offered back as a download. The service worker caches the tool itself so the second visit is instant and works offline.

If you want the full architecture in one breath: static HTML + WASM workers + IndexedDB for the few things we persist (recent files you opened, your favourites, in-progress workflows). No accounts. No telemetry on user content.

Try it

Compress a PDF — open DevTools → Network tab while you do it. Zero outbound requests for your file.
Disconnect from Wi-Fi after a tool has loaded once. It still works.
Drop a 200 MB PDF. It processes in roughly the time it would take just to upload, because the upload step doesn't exist.

Whether you stay on SnapToolz or use any of the other excellent local-first projects out there, the point holds: for everyday file work, your browser is now a capable enough operating system that the cloud doesn't need to be in the loop.

Tools used in this guide

Run it as a workflow

FAQ

Doesn't running everything in the browser drain my battery?: It uses your CPU instead of someone else's, so yes, slightly more than scrolling Twitter. But a typical PDF compression finishes in a few seconds — the energy cost is dominated by your screen being on, not the compute. For long videos or huge images, the trade-off shifts; we surface progress + a cancel button so you stay in control.
What about huge files my laptop can't handle?: Browsers can address up to a few gigabytes of memory per tab on a modern machine. Beyond that we recommend the desktop build (Tauri), which gets you native file streaming and the ability to chunk through files larger than RAM.
Can I trust that the code really doesn't upload?: Open the Network tab in your browser's DevTools while you use a tool. You'll see the static assets load once, and after that, nothing. The source is also published — you can audit it directly.
What happens if I close the tab mid-process?: The operation cancels; nothing was sent anywhere to begin with. There's no half-uploaded state to clean up. Open the tool again and you start fresh.