What "client-side" actually means.

Every "free online tool" says "client-side" or "your files never leave your browser." Most of them mean it in the sense that a restaurant says "fresh ingredients" — broadly true, shaped by what they need the sentence to accomplish. A smaller subset means it technically. An even smaller subset means it architecturally.

The word collapses at least five distinct claims. This piece breaks them apart, admits the three places even a well-meaning "client-side" tool can still leak, and ends with a 90-second procedure for verifying the claim yourself — no trust required.

Five meanings of "client-side."

Here are the five things people can mean when they say it. A given tool might occupy any of them.

#	Claim	What it actually promises
1	"Runs in the browser"	The JavaScript executes on your machine. But the file may still be uploaded.
2	"No file upload"	Your file doesn't leave. But metadata about your file (name, size, format) still might.
3	"Zero network requests after page load"	Strict. The tool doesn't talk to any server after the page renders. Except analytics. Usually.
4	"Offline-capable"	You can disconnect and it still works. Implies client-side. Doesn't promise no prior tracking.
5	"Fully local and audit-able"	You can inspect every line of code running and verify the network tab shows zero outgoing requests for your data.

Claims #1 and #2 are the normal ones. #3 is stricter. #4 is the PWA pitch. #5 is what most people actually want when they're worried about privacy. Most tools saying "client-side" mean #1 or #2; people hearing it often infer #5.

What client-side does protect you from.

Before listing the leaks, the promise is real for several common threat models. If a tool processes your file in the browser (not on a server), you are protected from:

Server-side breach. If the tool's company gets hacked next Tuesday, your file isn't in their logs, database, or S3 bucket, because it was never there. The company literally has nothing about you to lose.

Subpoena and legal compulsion. A subpoena served to a server-based tool's parent company can compel them to hand over whatever they have. If they never had your file, compulsion produces nothing.

Quiet internal use. Server-based tools can (and some do) sample user uploads to train models, improve algorithms, build datasets, or just let employees look. Client-side tools structurally can't — your file isn't on their machines to look at.

Insider threat. A disgruntled engineer at a server-based tool can read user files. At a genuine client-side tool, there's nothing to read.

That's a lot of real protection. The claim is not empty. The point of this piece isn't to dismiss "client-side" — it's to draw the honest line around what it does and doesn't cover.

The three ways it still leaks.

Here are the leaks that can happen even when the processing itself is entirely client-side.

1. Third-party fonts and stylesheets

Most websites load their fonts from Google Fonts or a similar CDN. When your browser renders the page, it makes an HTTP request to fonts.googleapis.com, which transmits your IP address and user agent to Google. Google logs this. Even though your file never uploaded, the fact that you opened this particular tool at this particular time did.

This is usually legal, usually boring, and usually unrelated to the file you care about. But it's a technical leak: a third party now knows you visited. Full-private tools either self-host fonts or use system fonts. Most don't.

2. Analytics, even the privacy-friendly kind

Most tools load an analytics script. The best-case version is something like Plausible or Fathom, which send a single aggregated pageview ping with no cookies, no IDs, no cross-site tracking. That's genuinely minimal. But it's still a network request, it still includes your IP address at the TCP level, and it still constitutes a log entry somewhere saying a browser matching this profile opened this tool at this time.

If the tool uses Google Analytics instead, the leak is much larger: cross-site tracking cookies, ad-targeting signals, and a profile Google can merge with every other Google-loaded site you've visited this year.

3. Error reporting and observability

This one is the sneakiest. Some tools load Sentry or similar error reporters, which snapshot the runtime state whenever an exception fires. Including, potentially, parts of the DOM, the URL, local variables. If an error fires while your sensitive file is in memory, the error report can include its contents. This happens quietly — the user never sees it and the tool operator rarely thinks about it.

The fix is either not loading error reporters at all, or scrubbing payloads before they send. Both are easy; neither is default.

How to verify any tool's claim in 90 seconds.

This is the only part of the piece you really need. Don't trust any tool's claim — including ours. Verify it:

1. Open the tool's page. Don't do anything yet.
2. Press F12 (Cmd-Option-I on Mac) to open DevTools.
3. Go to the Network tab and check the "Preserve log" checkbox. This means requests won't clear when the page navigates.
4. Reload the page. Note all the requests that fire on load. Fonts, analytics, the page itself. This is the "ambient" cost of opening the tool.
5. Now use the tool. Drop a file onto it. Run the conversion. Download the output.
6. Look at the Network tab again. Any new requests that appeared since you started using the tool are what the tool transmits when you actually use it.

If step 6 shows zero new requests originating from your file's content, the tool is genuinely client-side. If it shows requests with suspiciously large payloads — particularly anything that looks like it could fit your file — the tool is transmitting your data somewhere, whatever it says on the box.

This test takes 90 seconds and cannot be faked. It works on any web tool you've ever visited. The only thing you need to trust is that your browser's DevTools aren't lying to you — and DevTools is built into the browser, shipped by Google/Mozilla/Apple, and independently auditable.

What "client-side" never protects you from.

Three threats that no amount of client-side purity can address. Worth naming so the claim doesn't get oversold:

A compromised device. If your laptop has malware, nothing the website does matters. The malware sees everything you type, open, and render.

A hostile browser extension. Extensions have deep access to page content. A compromised extension can read any file you drop onto any tool, regardless of where that tool's server is. Audit your extensions periodically.

A malicious update. Even a genuinely client-side tool can become non-client-side tomorrow if the maintainer pushes a new version that adds upload. The version you audited is the version you got on the day you audited it. For a tool you use often with sensitive data, it's worth re-running the 90-second check every few months.

"Client-side" is a property of code, not of intent, and the code can change. The verification above is a snapshot, not a subscription.

Where the workshop lands.

Honest assessment of where Tooly McToolface sits on the five-meanings spectrum:

Claim #1 (runs in browser): Yes. Every tool. The JavaScript is visible in your DevTools' Sources tab — the whole tool fits in one HTML file, which means the code you'd audit is the code that runs, with no bundler obfuscation.

Claim #2 (no file upload): Yes. Files pass through the File API and Blob primitives and never get transmitted. Verifiable via the Network tab test above.

Claim #3 (zero network after page load): Almost. One Plausible analytics ping fires when the page loads, and that's it. No analytics on tool actions, no event tracking, no error reporting. The privacy page names the single exception explicitly.

Claim #4 (offline-capable): Yes. The site installs as a PWA with a service worker that caches everything. After one visit online, every tool works offline. Pull airplane mode — they still run.

Claim #5 (fully audit-able): The audit-able part is yes — every tool's source is the deployed HTML, viewable via View Source. The only external dependencies loaded at runtime are Google Fonts (one HTTP request to fonts.googleapis.com on page load) and the Plausible script. Neither ever sees your file.

Fonts are the last leak we haven't fixed. Self-hosting them would eliminate it; we haven't yet because the file-size cost is real and the privacy cost is small. If you want zero external requests including fonts, run a tool, then Save Page As from your browser, and open the saved HTML. It'll use your system fonts. Everything else still works.