Is this browser tool really client-side?

Updated May 4, 2026 · 6 min read · by Samuel Yoo

A site that says “100% in your browser” can still send your data over the network. The phrase is a marketing claim, not a technical one. Before pasting a JWT, an API key, a password, a private key, or anything you wouldn’t email to a stranger, take 90 seconds and verify.

This guide is three checks you can do in any modern browser without installing anything. They work on any web tool, not just ours. If you do them once a month — on the tool you reach for most — you’ll catch the silent uploaders fast.

Check 1 — Open the Network tab and watch what gets sent

This is the single most useful thing you can do. Every modern browser ships with a Network tab. Open DevTools (F12 or right-click → Inspect), click Network, and turn on Preserve log. Then use the tool the way you normally would: paste your data, click the button, see the result.

Watch the request list as you type or paste. A truly client-side tool makes zero new requests after the page loads. Look for:

• POST requests to any endpoint after the initial page load. Anything named /api, /process, /decode, /parse, /upload is a red flag. Click it. Look at the request body. If you see your data in there, the tool sent it.
• WebSocket connections. A ws:// or wss:// connection that appeared after you pasted is a streaming upload. Less obvious than a POST, but the same outcome.
• Beacon requests. These are short-lived “fire and forget” pings used by analytics. They’re usually small (a few hundred bytes) but can carry sensitive payloads. The sendBeacon() API doesn’t show up in the same way as fetch — filter Network for “beacon” and “collect” if you want to be thorough.

What’s fine to see:

• Initial page load — the HTML, JS, CSS, fonts, favicons. Those happen once when you arrive, before you’ve pasted anything.
• A pageview ping to an analytics endpoint — many tools (including ours) load Cloudflare Web Analytics or similar privacy-friendly counters. Check the request body: if it’s just {url, referrer, ts} and not your data, that’s fine.

If a tool is genuinely client-side, the request count should not change when you operate the tool. That’s the gold-standard test.

Check 2 — Disconnect from the internet, then use the tool

Less subtle, but harder to fake. Once the page has loaded, switch to Offline in the Network tab (the dropdown that usually says “No throttling”). Or unplug your Ethernet cable. Or turn on Airplane Mode.

Then use the tool. If it still works, the math is happening in your browser. If it spins forever or shows a “network error”, the tool needs to talk to a server to do its job — meaning it sends your data.

This works because static, client-side tools are pure JavaScript: once the page is in your browser’s memory, the network is no longer needed. Tools that pretend to be client-side but actually proxy to an API will fail this test instantly.

A subtle gotcha: some tools download a worker script only when you click the button (lazy-loaded code). Those will fail this test even though they’re client-side. The fix: click the button once while online, then go offline and click it again. If it works the second time, it’s client-side.

Check 3 — Read the JS source (skim, not deep-dive)

This sounds intimidating. It’s not. You don’t have to read all the code — you have to grep it for two things.

Open DevTools → Sources (or Debugger in Firefox). On the left you’ll see a tree of every script the page loaded. Open the one that looks like the tool’s main bundle (usually named index.js, main.js, or something with a hash like app.abcd1234.js).

Press Ctrl/Cmd + F inside the source view to search the file. Search for these strings:

• fetch( — every outgoing HTTP request in modern code uses fetch. If the file has zero matches, the tool can’t send your data anywhere.
• XMLHttpRequest — older API; same idea.
• WebSocket( — streaming upload primitive.
• sendBeacon — the analytics ping API mentioned above.

If you find one, look at what URL it’s calling. Most legitimate hits will be something like https://cloudflareinsights.com/cdn-cgi/... (analytics) or /sitemap-index.xml (a sitemap fetch). Suspicious ones look like /api/decode, /process, or third-party domains you don’t recognise.

Don’t try to read the surrounding logic. Just confirm: are there fetches to anywhere except analytics? If yes, dig deeper. If no, the tool is client-side.

What “open source” buys you, and what it doesn’t

A tool’s GitHub link is comforting but doesn’t prove anything by itself. The site you’re using might be running a different version of the code than what’s published. Read the deployed bundle (Check 3) — that’s the version actually running in your browser.

A signed Subresource Integrity hash on the <script> tag would prove the served bundle matches a specific commit. Almost no tool ships SRI hashes today, so this remains a “trust the deployed code” exercise.

When client-side is non-negotiable

Three categories of paste deserve all three checks every time, on every tool, even ones you’ve used before:

• Production secrets — JWTs from real users, real API keys, real database passwords, real session tokens. Even a “no upload” tool that silently logs your input to its analytics is a breach.
• Personal data — addresses, phone numbers, IDs. Privacy regulation may force you to use only client-side tools for these.
• Anything covered by an NDA — code, contracts, internal docs. Pasting these into a tool that reverse-proxies them to a logged request log is a contract violation.

For everything else — formatting public JSON, decoding a base64 of your own resume — convenience usually beats paranoia.

How tooljo passes these checks

We pass all three. Every tooljo tool is a static page; no API, no backend service, nothing to upload to. The full set:

• Network tab: the page makes ~5 requests on first load (HTML, JS, CSS, font, favicon) and zero after. Try it — open the Network tab on json.tooljo.com and paste a JSON. The request count won’t change.
• Offline test: every tool works offline once loaded. Try this too — load any of our pages, switch to Offline in DevTools, then use the tool.
• Source grep: our bundles contain zero fetch() calls. We don’t even ship Cloudflare Web Analytics on the dev tools subdomains — there’s nothing to send.

If you ever find a tooljo tool that fails any of these three, please email us — that’s a bug, not a feature.