Online Tool Security: How to Tell If a Site Processes Data Locally

You paste an API key into a "free JWT decoder." You drop a CSV full of customer emails into an online "CSV cleaner." You run a config file through a web-based formatter. In each case, one of two things just happened: the tool processed your data in your browser, or it uploaded it to someone else's server.

Most people have no idea which. The site usually does not tell you, and "we value your privacy" boilerplate in the footer is worth exactly nothing. The good news: in most cases you can figure it out in under a minute with your browser's built-in DevTools. No special skills required.

This article walks through the exact checks you can run on any online tool — and explains what the results actually mean.

Why This Matters More Than It Used To

A few things have shifted in the last couple of years:

• Developers paste increasingly sensitive data into online tools (tokens, internal schemas, customer data, proprietary prompts).
• Ad-supported "free" tools have strong commercial reasons to log request bodies and feed them into analytics, LLM training pipelines, or third-party data brokers.
• Modern browsers are powerful enough that almost every utility — encoding, hashing, formatting, validating, converting — can run entirely in JavaScript/WebAssembly. When a tool still sends data to a server for one of these tasks, there is usually a reason, and the reason is rarely "technical necessity."

If you are handling anything remotely sensitive — credentials, personal data, internal configs, proprietary code — the cost of picking the wrong tool can be real. We covered the architectural case in Privacy-First vs Cloud-Based Developer Tools. This article is the practical follow-up: how do you actually verify a given tool?

The 60-Second Network Tab Check

This is the single most reliable test. It works on any browser (Chrome, Firefox, Edge, Safari, Brave) and takes about a minute.

1. Open the tool's page in a fresh tab.
2. Open DevTools (F12 on most browsers, Cmd+Opt+I on macOS) and switch to the Network tab.
3. Check Preserve log so entries survive page navigation.
4. Click Clear to start with a blank slate.
5. Paste a small, throwaway test input (e.g., the string TEST_INPUT_12345) and run the tool.
6. Look at the Network tab. Filter by XHR/Fetch and WS (WebSocket).

What you are looking for:

• No new XHR/Fetch/WS requests after clicking the tool's action button → the tool processed your data locally. This is what you want.
• An outgoing POST or WebSocket message containing your input → the tool sent your data to a server. Inspect the request to see where, and assume that server logged it.
• Requests to analytics or ad domains (Google Analytics, Segment, Mixpanel, Amplitude, Facebook, TikTok) → these are usually just telemetry, but check the request body. If your input appears in the payload, that is a serious red flag.

What "local" looks like in the Network tab: the only requests you should see after running the tool are (a) static assets like JS chunks or fonts that were already loading, and (b) analytics pings that do not contain your input. Nothing else.

The View-Source Check

If the Network tab looks suspicious, the source often confirms it. Right-click → View Page Source, or open DevTools → Sources tab, and search (Cmd/Ctrl+F) for:

• fetch( and XMLHttpRequest — all network calls funnel through these.
• /api/ — a common path prefix for server endpoints.
• FormData — often used to upload files.
• WebSocket — persistent connections for streaming processing.

If the main bundle contains fetch('/api/format', ...) and your input ends up in the body, the tool is server-side regardless of what its marketing says.

For formatted, non-obfuscated clients, this takes seconds. For minified or obfuscated bundles, skip it and trust the Network tab — the network doesn't lie.

Red Flags in the Marketing Copy

Some tells are obvious once you know what to look for:

• "Upload your file" as the primary verb. Legitimate client-side tools let you drag-drop or paste; they rarely need to "upload" anything.
• A file size limit measured in MB (10 MB, 25 MB, etc.) for simple formatting or encoding. Browsers can handle gigabytes locally. A size cap usually exists to protect the server's bandwidth.
• "Our servers never store your data" — this is a promise, not proof. A promise from a free tool whose business model you can't identify is worth roughly what you paid for it.
• A required account or API key for simple utility tools. Formatting JSON or generating a password has no reason to require login.
• Progress bars for trivial operations. Encoding a 500-byte string in Base64 should be instant. If there's a progress bar, something is making a round trip.

None of these are automatic disqualifiers, but any two of them together warrant a Network tab check.

Green Flags Worth Trusting

Conversely, a few signals are meaningfully positive:

• Works offline. Load the page, disable your Wi-Fi, run the tool. If it still works, the processing is local by definition. This is the gold standard test.
• Public source code. If the site is open source and builds reproducibly (ideally on a public CI), you can audit exactly what runs in your browser.
• No size limits on the kinds of operations that would be server-bottlenecked — a site that happily processes a 100 MB file in the browser is almost certainly local, because hosting that much traffic would be prohibitive otherwise.
• Static hosting headers. Check the response headers (Network tab → Doc → Headers). A site served from a CDN (cf-cache-status, x-vercel-cache, x-amz-cf-id, static server headers) with no dynamic backend is a strong hint the site cannot even process data server-side.

Walkthroughs: What Each Tool Category Should Look Like

Password generators

A password generator has no technical reason to contact a server. Entropy comes from crypto.getRandomValues() — a browser API. If you generate a password and see a network request, walk away. This is one of the most egregious categories because a password sent to a server is a password that has, in a meaningful sense, already been compromised.

Background on entropy and what makes a password strong: password entropy explained and how to generate strong passwords.

Hash generators

Hashing (SHA-256, MD5, etc.) is pure math. Browsers have had crypto.subtle.digest() for years. A hash generator sending your input to a server is doing so for reasons that are not about computing the hash. Compare algorithms in hash algorithms compared.

Base64 encoders and decoders

Base64 encoding is a handful of lines of code. btoa()/atob() has been in browsers since forever, and binary-safe versions are trivial to implement. A Base64 encoder with any network activity is a strong red flag. Deeper dive: Base64 encoding explained.

JWT decoders and encoders

This is the most dangerous category and the one most commonly done wrong. A JWT often contains user IDs, roles, tenant information, and — with encoded tokens — enough surface for an attacker to replay or analyze. A JWT encoder/decoder that sends your token to a server is logging your token on that server. If the token is still valid, it is effectively a credential leak.

Before pasting any JWT into an online tool, run the Network tab check. And read understanding JWT security for why that token in your clipboard is more dangerous than it looks.

JSON and YAML tools

Formatting, validating, and converting between JSON and YAML is entirely doable in the browser with mature libraries. If your config files contain anything sensitive — connection strings, API keys, secret paths — do the 60-second check first. Related: when to use JSON vs YAML.

A Reasonable Threat Model

Nothing above means "every server-side tool is malicious." Some tools genuinely need a server (OCR on images, heavy PDF rendering, certain video conversions). The question is whether the specific operation you are performing needs one, and whether the data you are sending is sensitive enough to care.

A rough mental model:

If you are unsure where a piece of data falls, err on the side of the stricter category. It costs nothing to use a local tool for public data. The reverse is not true.

What "Client-Side" Does Not Protect Against

Being honest about the limits:

• Browser extensions with broad permissions can read anything on any page. A compromised extension defeats client-side processing.
• Supply chain attacks on JavaScript dependencies can inject data-exfiltration code into otherwise-trustworthy sites. The 2025 npm package incidents are a reminder this is real. Mitigation: Subresource Integrity, CSP, and dependency pinning — but ultimately you are trusting the site's build pipeline.
• Local malware renders all of this moot. If your machine is compromised, a well-behaved website cannot save you.
• The clipboard is a sidechannel. Other apps on your machine can read what you copied. Relevant for shared/corporate machines.

Client-side processing raises the bar significantly. It is not a silver bullet.

A Practical Routine

What to actually do:

1. The first time you use any new online tool with remotely sensitive data: run the 60-second Network tab check.
2. Bookmark the tools that pass. Stop using the ones that don't.
3. For team-wide usage, put approved tools in your engineering handbook. For denied ones, document why.
4. Periodically re-check. A tool that was client-side last year can ship a "pro" feature that quietly adds a server call. The Network tab does not lie.
5. When in doubt, use offline-capable tools. If a tool keeps working with Wi-Fi off, you have cryptographic-level proof it is processing locally.

FAQ

Is "HTTPS" the same as "safe to paste secrets into"?

No. HTTPS only protects data in transit from network eavesdroppers. It does nothing to stop the server on the other end from logging your request. Every site that leaks user data does it over HTTPS.

Can I trust privacy policies that say "we don't store your data"?

Treat them as an aspiration, not a guarantee. Policies bind behavior only to the extent they are enforced, and enforcement against a free tool is rare. The Network tab gives you evidence; the privacy policy gives you vibes.

What about tools that say they process "in memory" on the server?

This is a common phrasing designed to sound like "we don't keep it," but the data still transits the server, gets parsed by server code, and may be logged by any layer in between (load balancer, web server, error tracker, analytics). "In memory" is not the same as "never left your device."

Does "open source" mean the tool is safe?

Only if the version running in your browser is provably built from the public source. Most "open source" tools publish a repo but ship a minified bundle you cannot easily verify. Reproducible builds and integrity hashes close that gap; most sites do not bother.

How does alltools.one handle this?

Every tool on alltools.one — the password generator, hash generator, Base64 encoder, JWT encoder, and the rest — runs entirely in your browser. No input is transmitted to any server. You can verify it yourself with the 60-second Network tab check. That is the whole point: you should not have to take our word for it.

Related Resources

• Privacy-First vs Cloud-Based Developer Tools: A Security Analysis — the architectural case
• Online Privacy Tools Guide — broader privacy toolkit
• Understanding JSON Web Tokens Security — why pasting JWTs into random sites is dangerous
• Generate Strong Passwords — what good generation looks like
• Password Entropy Explained — the math behind strong passwords