Skip to main content
DevBench
All articles
securitydevtoolsprivacyweb

Choosing privacy-first online developer tools (a practical checklist)

July 31, 20267 min read

Online developer tools are convenient — and often the wrong place for production secrets. The problem is rarely the feature itself (decode a JWT, format JSON, merge a PDF). The problem is opacity: you cannot tell whether the site is running JavaScript in your tab or quietly posting your paste to a server for “processing.”

This checklist is what we use when evaluating tools for DevBench, and what we recommend before you trust any random converter with credentials, customer data, or unreleased documents.

1. Open the Network tab before you paste anything sensitive

In Chrome or Firefox DevTools, open the Network panel, clear it, then perform the action (format, decode, hash, merge). For a true browser-only tool you should see no request that carries your payload — no POST /api/…, no WebSocket with the document body, no mysterious beacon with a Base64 blob.

Analytics and ad scripts may still fire on page load. That is different from uploading the text you typed into the tool. If you see your JWT or JSON leave the origin, treat the site as a third party with a copy of your data — regardless of what the marketing copy claims.

2. Demand an honest list of network exceptions

“100% client-side” is only trustworthy when the product also lists the features that do leave the browser. Legitimate exceptions look like:

  • A CORS proxy that forwards an HTTP request you explicitly send (API tester)
  • A webhook fire to a URL you typed
  • A remote compiler (for example the public Go playground) for a language that cannot run in-browser yet
  • An ephemeral convert endpoint that discards the upload after the response

Vague claims with zero exceptions are a red flag. So is a privacy policy that never mentions relays, proxies, or third-party compile APIs when the UI clearly needs them.

3. Prefer tools that teach, not only transform

Thin pages that only offer an input box and a green “Success” badge are easy to clone and hard to audit. Higher-quality tools explain the format, show common mistakes, and link to deeper guides — for example when Base64 is not encryption, or when a decoded JWT payload is not proof of authenticity without signature verification.

If the page cannot explain why a result is correct, you should be sceptical of the implementation quality behind the button.

4. Separate ads from your paste buffer

Many free sites fund hosting with advertising. That can be fine — if ad scripts are isolated from tool inputs. What you want to see in a privacy policy is an explicit statement that advertising partners do not receive the contents of the tool forms. Opt-out links (Google Ad Settings, YourAdChoices) are a good signal that the publisher is not pretending ads are invisible.

Affiliate bars that push unrelated products into every viewport are a different problem: they rarely steal your JWT, but they are a strong hint the product is optimised for clicks rather than craft.

5. A short workflow you can reuse

  1. Skim the privacy policy for “browser,” “client-side,” and any named exceptions.
  2. Open DevTools → Network; clear; run a harmless sample through the tool.
  3. If the sample leaves the tab unexpectedly, stop — do not paste real secrets.
  4. For credentials, prefer offline CLIs or self-hosted utilities when the risk is high.
  5. Close the tab when finished on a shared machine; clear downloads if you saved files.

How DevBench fits this checklist

Most DevBench utilities (JWT debugger, JSON/YAML formatters, hash generators, most PDF and image edits) run in your browser with Web Crypto, File APIs, and Web Workers. A small set of features use short-lived relays by design — API Tester, Webhook Simulator, Notebook → PDF, and the Go playground path to go.dev — and those are called out in the privacy policy. Site analytics and AdSense fund hosting; they are not wired to receive tool payloads.

If you are evaluating us the same way you evaluate anyone else: open the Network tab on the JWT Debugger or JSON toolkit, paste a synthetic sample, and verify the behaviour matches the documentation.

Try it yourself

Use the free browser-based JWT Debugger on DevBench — no signup, runs entirely in your browser.

Open JWT Debugger

Related articles

Browser code playgrounds: what runs where (and what never leaves your tab)

Online playgrounds mix iframes, WebAssembly, and remote compilers. Here is a practical map of which pieces stay local, which hit a third-party API, and how to choose a flow for secrets and stdin-heavy programs.

JWT Decoder Without Uploading to a Server

Decode JWT header and payload in the browser: why Base64 is not encryption, what stays local vs what never leaves your machine, and why decoding still isn’t verification.

How to Validate JSON Online (Safely)

Validate JSON before it breaks production APIs — what “valid JSON” means, how browser-only tools differ from server uploads, and a simple workflow you can repeat every time.

More articles

Browser code playgrounds: what runs where (and what never leaves your tab)

Online playgrounds mix iframes, WebAssembly, and remote compilers. Here is a practical map of which pieces stay local, which hit a third-party API, and how to choose a flow for secrets and stdin-heavy programs.

How Base64 encoding works — and when NOT to use it

Base64 turns binary into printable ASCII — useful for email, JSON, and data URIs. Here is how the encoding actually works, why it inflates size by ~33%, and the dangerous cases where people mistake it for encryption.

JWT security best practices — 10 things developers get wrong

JWTs are convenient, but misuse is everywhere: treating payloads as secret, skipping audience checks, weak HMAC keys, and storing tokens where XSS can read them. Here are ten concrete mistakes and what to do instead.

View all articles