What Runs in the Browser Now: A Capability Audit of 180 Client-Side Tools

“It runs in your browser, nothing is uploaded” is easy to say and hard to prove. So we did the boring thing: we went through the source of all 180 tools on this site and recorded, for each one, the specific browser capability that lets it work without a server.

This isn’t a marketing claim — it’s a count. And it turned into a decent snapshot of what the browser platform can actually do in 2026, which is a lot more than most people assume.

The headline number

Across all 180 tools, the number that send your input to a backend is zero. No tool uses sendBeacon or XMLHttpRequest to ship your data to our servers. The handful of fetch() calls in the codebase are either example code a tool generates for you (a curl-to-code snippet, say) or API-testing tools that call your own endpoint — never ours.

That’s the claim made concrete. Now the more interesting part: how do 180 different tools manage that?

What enables each tool

Assigning every tool a single primary capability gives this distribution:

A few things stand out.

Plain JavaScript still does the heavy lifting (42%). Formatters, converters, case changers, regex testers, color math — the largest slice of the catalog is just JavaScript manipulating strings and data structures. No special API, no library, no server. Every tool in Color & CSS (21 of 21) and String & Text (11 of 11) falls here. This is the unglamorous foundation: a huge amount of useful tooling needs nothing more than the language itself.

Half the catalog touches your files — locally. Counting every tool that reads a user-supplied file (not just those where it’s the primary capability), 89 of 180 tools (49%) use the File API or drag-and-drop to read a document, image, or archive you provide. Historically this is exactly the category that “had to” upload — and now none of it does. The browser reads the bytes into memory and works on them there.

Documents are the surprise. All 31 tools in Document & PDF run without a server. Most of that is pure JavaScript libraries — pdf-lib for editing, SheetJS for spreadsheets, Mammoth for Word — with a few genuinely WebAssembly-backed pieces, like pdf.js for rendering and a WASM build of qpdf for encryption. PDF editing was one of the last strongholds of “you need a backend for this.” It isn’t anymore. (We unpack the trade-offs in server-upload vs in-browser PDF editing.)

Crypto belongs in the browser. The 10 tools built on the Web Crypto API — hashing, password generation, token tools — use the browser’s own cryptographically secure primitives (crypto.subtle, crypto.getRandomValues). For generating secrets, the browser is not a compromise; it’s the correct place to do it, because the secret never has to exist anywhere else.

The AI category, honestly

The most hyped capability deserves the most careful accounting. The AI Tools category has 33 tools — but only 19 of them actually load and run a machine-learning model in your browser. The other 14 are algorithmic or heuristic: pattern-based generators and analyzers that don’t need a model at all. We counted only the 19 real ones as “in-browser AI,” because calling a rule-based generator “AI” would be the kind of overclaim this whole audit exists to avoid.

For the 19 that do run a model, there’s an honest nuance worth stating plainly:

This is the part of the platform that genuinely changed recently. Running a real transformer model in a browser tab — via WebAssembly and, increasingly, WebGPU — went from research demo to something you can ship. It’s slower than a datacenter GPU and the model has to download once, but for classification, extraction, and summarization of text you’d rather not hand to a third party, it’s a real option now.

Capability usage, counted without forcing one label

Assigning a single “primary” capability undercounts reality, because plenty of tools use several. Counting every capability a tool uses (multi-label):

• 85 tools read files via the File API
• 41 tools use Canvas or an image pipeline
• 32 tools pull in a document/Office library
• 19 tools run an in-browser ML model
• 11 tools use the Web Crypto API

The File API number (85) is the one to sit with. Reading and processing user files used to be the textbook reason to run a server. Today it’s the single most common capability in a catalog that has no backend at all.

What this says about 2026

Three takeaways from the audit:

1. The “you need a server for this” list got short. Files, documents, cryptography, and a meaningful slice of machine learning now run in the browser. The remaining genuine reasons to use a server — heavy batch jobs, multi-gigabyte models, shared state — are real but narrower than the default assumption.
2. Client-side is a privacy architecture, not just a performance trick. When the file never leaves the device, an entire category of risk (server retention, breaches, jurisdiction) simply doesn’t apply. That’s not a policy promise; it’s a property of where the code runs.
3. Be precise about the claims. “Runs in your browser” doesn’t always mean “never touches the network,” and not everything labeled “AI” runs a model. The interesting story holds up fine without rounding the edges off it — so we didn’t.

If you want to verify any single tool’s behavior yourself, the method is the same one from our PDF privacy guide: open the Network tab and watch whether your file leaves. For most of what used to require an upload, in 2026, it doesn’t have to.