It is 4pm, an API is returning 401, and you need to see what is inside the bearer token. You search for a JWT decoder, paste the token into the first result, and read the claims. Problem understood, bug fixed, day continues.
What also happened is that a working credential for your production system now exists on a server you have never heard of, owned by a company you did not evaluate, in a request log with a retention policy you did not read.
This is not a hypothetical risk and it is not a rare mistake. It is the single most common way that secrets leak out of otherwise careful engineering teams, and it happens because the tool that causes it is genuinely useful and takes four seconds to use.
What actually happens when you paste
Most online developer tools are server-rendered. You paste, the page POSTs your input to a backend, the backend transforms it, and the result comes back. That architecture is not malicious — it is simply the easiest way to build a web tool, and for a long time it was the only way.
But it means your input passes through, and is very likely recorded by, several layers you cannot see:
- The application log. Request bodies are logged by default in a great many frameworks, particularly in development configurations that quietly made it to production.
- The reverse proxy or CDN. Access logs, and sometimes full request capture when debugging is enabled.
- Error tracking. If your input triggers an exception, tools like Sentry attach the request body to the report — and that report goes to yet another third party.
- Backups. Everything above gets backed up, and backups outlive deletion requests.
None of that requires anyone to be acting in bad faith. The operator of a free JSON formatter is not reading your payloads. But "nobody is currently reading it" is a very different security property from "it was never sent".
The categories of secret people paste without thinking
When people hear "don't paste secrets", they picture a password field. The actual leaks look nothing like that. In rough order of how often they happen:
JWTs and bearer tokens
A JWT is not a description of a session — it is the session. Anyone holding it can act as that user until it expires, and expiry times of hours or days are common. Debugging authentication is precisely the situation that makes you want to decode one, which is why this is the most frequently leaked category by a wide margin.
API responses
You paste JSON to format it because it is unreadable, and it is unreadable because it is large. Large API responses contain customer email addresses, internal user identifiers, billing references and occasionally an embedded access token for a downstream service. You were looking at the structure; you transmitted the contents.
Configuration files
A docker-compose.yml or a Helm values.yaml pasted
into a validator carries your internal hostnames, registry addresses,
service topology and — far more often than anyone admits — a database
password sitting in an environment block where a secret
reference should have been.
Base64 blobs
Base64 is the wrapper around things that are not text. Basic-auth headers
are Base64 of user:password. Kubernetes Secret values are
Base64. A "let me just decode this to see what it is" reflex is, quite
often, a decision to transmit a credential in order to discover that it was
a credential.
Why "it's encoded" is not protection
It is worth stating plainly, because the confusion is widespread and expensive: Base64 is not encryption. It is a reversible encoding with no key, designed to move arbitrary bytes through a text-only channel. Anyone who sees the string can decode it instantly. That is its entire purpose.
Kubernetes Secrets are the canonical trap. Their values are Base64 encoded, which leads a lot of people to believe they are protected at rest. They are encoded, not encrypted, unless encryption at rest has been explicitly configured on the cluster. A Base64 string in a leaked manifest is a plaintext secret with an extra step.
If you can reverse it without a key, it was never a secret. Encoding hides things from casual reading, not from an attacker.
What to do instead
Use tools that run in your browser
Decoding a JWT, formatting JSON, computing a SHA-256 and generating a password are all operations that need no server whatsoever. Modern browsers ship a JSON parser, a full cryptographic library in the Web Crypto API, and a cryptographically secure random number generator. A tool that uses them cannot leak your input, because it never has it.
You can verify this claim rather than trusting it. Open your browser's network panel and watch what happens when you use the tool. Better still, disconnect from the network entirely — a genuinely client-side tool carries on working, and a server-backed one stops immediately. That test takes ten seconds and settles the question completely.
Use the tooling you already have
For one-off work, the command line is right there and never leaves the machine:
jq .formats JSON.base64 -ddecodes Base64.shasum -a 256 filecomputes a checksum.openssl rand -base64 32generates a strong random secret.
Redact before you paste, when you must paste
Sometimes you genuinely need a colleague, a vendor or a support engineer to look at a payload. Replace the values, not just the obvious ones — token, password, email, internal hostname, customer identifier — before it leaves your machine. Structure is almost always what the other person needs; contents almost never are.
Rotate afterwards, without drama
If you have already pasted a live credential somewhere, the useful response is not embarrassment, it is rotation. Revoke the token, cycle the key, change the password. It takes minutes and converts an open-ended exposure into a closed one. Teams that treat rotation as routine maintenance rather than as an incident get this right; teams where rotation is a big deal tend to leave leaked credentials in place and hope.
The rule, compressed
Before pasting anything into a web page, ask one question: if this string appeared in a public log tomorrow, would I have to do something about it? If the answer is yes, it needs to be handled by a tool running on your own machine — whether that is your terminal or a page that does the work in the browser.
Every tool on this site is built to that standard, which is why none of them have a backend. It is a real constraint and it makes some things harder to build. It also means the question above never has an uncomfortable answer.