Why your developer data should never leave the browser

Most online developer tools have the same architecture: you paste data into a textarea, hit a button, and your data travels across the internet to someone else’s server, gets processed there, and the result comes back.

For a public JSON snippet that’s fine. For a real payload with tokens, customer data, or your database query — it’s a habit worth questioning. Every DevFormat tool runs entirely in your browser tab. Your data never touches a server, and nothing is logged. This post is about why that design is the right default, and where it actually matters.

Where tools really send your data

The tell is usually in the fine print: “By clicking, you agree to our processing your data” or a privacy policy that names subprocessors. If the conversion happens server-side, then the operator of the site — and anyone with access to their infrastructure, their analytics, or a subpoena — can see what you pasted.

Some tools do this because the computation genuinely needs a server (large language model helpers, heavy computation). But a JSON pretty-printer, a Base64 encoder, or a JWT decoder needs no server. It is a few kilobytes of code that runs fine in a browser. When such a tool still uploads your data, the upload is a choice, not a requirement.

What leaks when you paste it

Three classes of data end up in developer tools more often than people expect:

• JWTs and API keys. A JWT is a signed token that often contains your identity, roles, and expiry. Decoding it is trivial and requires no secret. There is no reason for that token to leave your machine. API keys, similarly, are copied into tools and pasted into tickets with alarming frequency.
• Real database rows. Testing a JSON-to-SQL converter with production data that includes names, emails, or PII is how accidental disclosure happens.
• Internal configuration. Schemas, endpoints, and internal formats are exactly what an attacker wants. Internal-only documents should stay internal.

None of this requires malicious intent on the tool’s part. Logs get breached, analytics vendors have data retention policies, and “we don’t read your data” is not the same as “your data never leaves your network.”

Client-side is the safe default

When processing happens in the browser:

• Your data never hits a network request. Nothing to intercept, log, or breach.
• The site can’t see what you pasted, because it never sends it anywhere.
• It works offline. There’s no server round-trip, no latency, and no “service is down.”

The main trade-off: the tool’s code runs in your browser, so it can only do what a browser can do. For parsing, formatting, validation, and conversion of developer data, that’s more than enough.

When you still need to be careful

Client-side is not a magic shield:

• The page could still load tracking scripts that observe interactions. A privacy-conscious tool should have no analytics on pages where you paste sensitive data — or at least you should know what it collects.
• Your data is only as safe as your machine. If your browser tab is compromised, client-side processing doesn’t save you.
• Extensions can read your tabs. Browser extensions with broad permissions can see everything you paste anywhere. It’s worth knowing what extensions you run.

The practical habit

Treat developer tools the way you treat cat file.txt | jq on a terminal: the data stays on your machine unless you explicitly send it somewhere. Before you paste a JWT, a live database row, or an internal schema into an online tool, ask one question: does this tool run locally, or is it sending my data to a server?

If it can’t answer clearly, use a tool that runs in your browser. Everything on DevFormat — from the JSON formatter to the JWT decoder to the SQL formatter — is client-side. Nothing you paste ever leaves the tab. That’s a deliberate design choice, and it should be the industry default.