How to Audit Your Browser Tools for Privacy and Security

Every day, developers paste sensitive data into online tools without a second thought — a production API response into a formatter, a private key into a converter, a customer export into a validator. Most of the time nothing bad happens. Sometimes it does, and the cost of that "sometimes" is high enough that it's worth knowing how to vet a tool before you trust it. The good news is that auditing a web tool takes about two minutes, requires no special expertise, and works on any tool on the internet. Here's the checklist I use.

The fifteen-second test: watch the Network tab

The single most revealing thing you can do with any online tool is open your browser's developer tools and watch what leaves the page. The Network tab is a live log of every request the page makes. If a tool claims to be "private" or "client-side" but quietly ships your input to a server, this is where you'll catch it.

Here's the procedure, step by step:

• Open the tool, then open DevTools (press F12, or right-click and choose Inspect). Switch to the Network tab.
• Tick "Preserve log." This stops requests from being cleared when the page navigates or reloads, so you don't miss anything.
• Clear the log (the circle-with-a-line icon) so you start fresh after the page has loaded.
• Enter a clearly fake, unique test input — something like ZZZ_TEST_MARKER_9988. Use the tool as you normally would: paste, click, generate.
• Watch the Network tab. If any request appears whose payload contains your test marker, the tool is transmitting your input to a server.

That's the whole test. A genuinely client-side tool will show only the background requests it always makes — analytics, ad scripts, font loading — and none of them will contain your input. A server-side tool will show a request carrying your test string, and you've just learned everything you need to know.

Reading the request details

When you click on a request in the Network tab, you can inspect its details. A few things tell you what's really happening:

• The request method: GET requests fetching assets are normal. POST, PUT, or PATCH requests are the ones that typically carry your input as a payload — click into the "Payload" or "Request" tab to see what's being sent.
• The destination domain: is the request going to the site you're on, or to a third party? A request to an unknown analytics or "processing" domain carrying your data is a serious red flag.
• The payload contents: if your test marker appears in the request body, the tool is leaking your input. No ambiguity.

Red flags beyond the network

Network behavior is the most decisive signal, but it's not the only one. A few other indicators that a tool deserves extra scrutiny:

Heavy tracking scripts

Even if a tool is client-side, the page itself can be loaded with trackers — analytics, advertising pixels, fingerprinting scripts. None of these see the contents of your computation, but they do build a profile of your visit. If a simple utility page is running twenty tracking scripts, the operator's priorities are telling you something. I've seen JSON formatters that load Google Analytics, Facebook Pixel, Hotjar, and three ad networks before the formatter even renders.

No source code and no explanation

A trustworthy tool usually explains how it works, and ideally lets you read the code. A page that demands you trust it on faith, with no technical detail and no link to its source, gives you no way to verify its claims. The strongest tools publish their code — even minified, the fact that it's there to inspect matters. My own tools at Duc Nguyen are all client-side and you can verify them in the Network tab yourself.

Requests to unexpected domains on input

The cleanest tools load everything they need once and then sit quiet. If pasting input triggers a flurry of requests to domains you don't recognize, treat that as suspicious. A client-side tool should not need to phone home when you type.

HTTPS is necessary but not sufficient

A site without HTTPS is an immediate no — never paste anything sensitive into a page served over plain HTTP. But the presence of HTTPS (the lock icon) only means the connection is encrypted in transit. It tells you nothing about what the server does with your data once it arrives. I covered this distinction in why client-side tools protect your privacy: encryption in transit is not privacy at rest.

The trust hierarchy

After running these checks, tools fall into a rough hierarchy. Knowing where a tool sits helps you decide what data it's safe to feed it:

• Highest trust: client-side, source available. The computation happens in your browser, and you can read the code. Examples include the tools on this site, which are open and verifiable in the Network tab.
• Good trust: client-side, no obvious leaks. The Network tab shows no data leaving, even if the source isn't published. Fine for most inputs, with mild residual caution.
• Conditional trust: server-side but reputable. The tool processes data on its server, but the operator has a clear privacy policy and a reputation to protect. Acceptable for non-sensitive data; never use for secrets, keys, or private customer data.
• No trust: server-side, opaque, or leaking. The tool transmits your input and offers no transparency. Don't feed it anything you wouldn't publish publicly.

What I build against, and why

This checklist isn't theoretical for me — it's the standard I hold my own tools to, and the reason they're built the way they are. When I ship a JSON formatter or a hash generator, it has to pass its own audit: no network request carrying user input, ever, regardless of what's pasted in. That's only achievable because the tools are architecturally client-side; there's no server for the data to reach even if something went wrong. You can run the fifteen-second test on any tool on this site and confirm it for yourself.

The point of publishing this checklist isn't to steer you toward my tools specifically. It's to give you a durable skill: the ability to evaluate any online utility, anywhere, in under two minutes. The web is full of convenient tools, and many of them are perfectly safe. A handful are not. Knowing how to tell the difference is the difference between convenience that's genuinely free and convenience that quietly costs you something.

A quick pre-flight routine

If you handle sensitive data regularly, make this a habit before pasting into any unfamiliar tool: open DevTools, watch the Network tab, paste a test marker. Two minutes, every time. Once you've done it a few times it becomes automatic, and you'll develop a shortlist of tools you've already vetted and trust. The ones that don't pass, you'll simply stop using — and that's a quiet, significant improvement to your security posture that costs you almost nothing.

Build this habit into your workflow explicitly. When you start a new week, check which online tools you used the previous week and run the fifteen-second test on any you haven't vetted yet. Over a month, you'll have audited every utility you rely on, and you'll have a clear mental model of which ones deserve your trust and which ones are fine only for throwaway data. The cost is a few minutes per tool, amortized across every future use. Most developers I've shared this with report that after the first month of auditing tools as they encounter them, the habit runs on autopilot — they open DevTools alongside a new tool the way they naturally reach for ad-blockers and password managers. It becomes part of a baseline security posture that operates without conscious effort, and that's precisely where you want it.

And if you're building tools yourself — even small internal ones — consider making them verifiably client-side from the start. The architecture choice costs nothing upfront (static files are cheaper to host than a server anyway), and it turns a privacy promise from a marketing claim into something your users can confirm with DevTools in fifteen seconds. That's the kind of trust you can't buy, and it's the only kind that matters for tools that handle sensitive input. When every user can independently verify that their data stays on their device, you've eliminated the need for privacy theater entirely, and you've built a relationship with your audience that's grounded in verifiable fact, not aspirational promises.

Common mistakes developers make when auditing

Even with the Network tab open, it's easy to misread what you're seeing. Here are the pitfalls I've watched smart developers fall into:

• Confusing asset loads with data exfiltration. A request for vendor.js or a font file is normal. Look at the payload, not just the URL.
• Not waiting long enough. Some tools batch data and send it on a timer. Watch for 10–15 seconds after your action.
• Missing WebSocket connections. The Network tab has a "WS" filter — check it. Persistent WebSocket connections can stream data continuously.
• Ignoring third-party iframes. An embedded widget (chat, payment, recaptcha) lives in its own frame with its own Network tab. Click into the frame to inspect.