Is it safe to paste a token or config into an online tool?
Only if the tool runs in your browser. A JWT is a bearer token — whoever holds it can use it until it expires — so pasting one into a decoder that posts to a server has handed over a working credential, not a puzzle.
Updated 2026-08-25
A JWT is a credential, not a puzzle
The most common version of this mistake is pasting a JSON Web Token into an online decoder to see what is inside it. The token looks like opaque gibberish, so it feels like something to be inspected rather than something to be protected.
It is neither opaque nor inert. The first two parts of a JWT are base64url — not encrypted, merely encoded — so the header and payload can be read by anyone holding the string, without any key at all. That is by design: the signature exists to prove the token has not been altered, not to hide what it says.
And it is a bearer token. Bearer means exactly what it sounds like: possession is authorisation. Whoever holds that string can present it and be treated as you until it expires. Pasting one into a tool that sends it to a server has not revealed a secret to be studied — it has handed over a working key to whoever runs the server, plus anything in their logs.
The payload usually makes it worse. Typical claims include a user id, an email, a tenant or organisation identifier, roles and scopes. So even an expired token discloses account structure, internal identifiers and permission model — useful reconnaissance long after the token itself is dead.
The other things people paste
Tokens are the sharpest case but not the most frequent. A few patterns account for most of the exposure.
Configuration files into a JSON or YAML validator. Config is exactly where connection strings, API keys and passwords live, and a file that will not parse is precisely the one you paste somewhere to find the missing bracket. The formatter does not care what the values are.
Log excerpts into a regex tester, to build a pattern that matches them. Logs carry email addresses, IP addresses, session identifiers, order numbers and sometimes full request bodies. Being real data is what makes them useful for testing the pattern, and it is also what makes pasting them a disclosure.
Base64 strings, decoded "to see what they are". Base64 is an encoding, not encryption — it exists to move binary safely through text channels, and reversing it needs nothing but the alphabet. Treating a base64 blob as though it were protected is a common and consequential error, and the blob is frequently a credential someone encoded precisely because it looked safer that way.
How to tell where a tool runs
The claim "we process everything client-side" is free to make, and plenty of sites make it while posting your input to an endpoint. Fortunately it is one of the few privacy claims an ordinary user can verify in under a minute.
Open your browser's developer tools, go to the Network tab, clear it, then paste your input and run the tool. If the work happens locally, nothing new appears — no XHR, no fetch, no beacon. If a request goes out carrying your data, you will see it, and you can click it and read exactly what was sent.
Two things to watch for. Test with harmless placeholder data first, not the real token — the check is only useful before you paste the thing you care about. And look past the obvious request: analytics and error-reporting scripts sometimes capture form contents, so a tool can be honest about not uploading your input while a third-party script does it anyway.
A tool that works with the network disconnected is the strongest signal available. Load the page, go offline, then use it. If it still works, the processing is genuinely local, because there is nowhere else for it to have gone.
When it has already happened
Assume disclosure and act on that basis, because you cannot un-send it and you generally cannot verify what was retained.
For a token or key, rotate it. Revoke the old one rather than merely issuing a new one — an unrevoked token stays valid until it expires regardless of what else you create. For an API key, most providers let you delete and reissue in a couple of clicks, and the cost of doing so unnecessarily is far lower than the cost of not doing it when it mattered.
For a password, change it wherever it is used, which for most people is more places than they remember. For a config file, treat every credential in it as exposed, not only the one you were debugging.
Then check whether it was ever committed. Secrets pasted into a tool are frequently secrets that also live in a repository, and a key removed from the working tree stays in the history. Rotating the credential is the fix; deleting the line is not.
A working habit
The realistic goal is not to stop using online tools — they are genuinely useful and the alternative is often installing something worse. It is to make the safe path the default one.
Redact before pasting. Replace the signature of a JWT with a few characters, swap real keys for `REDACTED`, change email addresses to `a@b.com`. Most of these tools are being used to check structure, and structure survives redaction perfectly. If you are looking for a missing comma, the values are irrelevant.
Prefer tools that run locally, and prefer the ones that let you check. A page that keeps working with the network off has proved the claim rather than asserted it, and that is a property you can test once and then rely on.
And keep a sense of proportion. Formatting a public API response, decoding a base64 string from a blog post, or testing a regex against invented sample data are all fine anywhere. The rule that matters is narrow: **if the input would be a problem in someone else's logs, it needs a tool that never sends it.**