Pasting a JWT into an online decoder is a security incident
· 5 min read
It takes four seconds and feels harmless. You copy a token out of a failing request, paste it into the first decoder Google offers, and read the claims. In a lot of organisations you have just created a reportable event.
What actually happens when you paste
A JWT is three Base64url segments. Decoding it is a handful of lines of JavaScript — there is no technical reason for the work to happen anywhere but your browser. Yet a large share of the popular decoders POST the token to a backend and render the response.
You can check any tool in about ten seconds. Open your browser devtools, switch to the Network tab, paste the token, and watch. If a request goes out carrying your input, the tool has your token. Do the same on the JSON formatters and Base64 decoders you have bookmarked; the results are often surprising.
Why a decoded token still matters
The usual defence is that a JWT payload is not encrypted, so nothing was disclosed by decoding it. That misses the point twice over. First, the signature travelled with it — whoever received that token can replay it against your API until it expires, with whatever scopes it carries. Second, the payload routinely contains a user id, an email address, a tenant identifier, and role claims. Under GDPR that is personal data, and it now sits in a third party's logs.
The window is often longer than people assume. Access tokens with an hour of life are common; refresh tokens last far longer. "It expires soon" is a hope, not a control.
The same problem, everywhere else
Tokens are the sharpest example, not the only one. The config file you pasted into an online YAML validator had a database password in it. The API response you formatted contained customer records. The CSV you converted to JSON was an export of your user table. The PDF you merged was a signed contract.
None of these feel like data exfiltration in the moment, because the mental model is "I used a tool", not "I uploaded a file to a stranger". The architecture is what decides, not the intent.
What to do instead
Prefer tools that do the work in the browser and can prove it. Local-first tools make no network request at all, so the Network tab stays empty no matter what you paste. Toolbit is built this way on purpose: there is no backend to send anything to, and the source is open so the claim is auditable rather than a promise.
Where you cannot verify a tool, use a throwaway token or redact the payload first. And if a token has already been through a service you do not control, treat it as compromised: revoke it, rotate the signing key if the token was signed with a shared secret, and move on. Rotation is cheap. Explaining an incident is not.
Frequently asked questions
- Is it safe to decode a JWT in Toolbit?
- Yes. The JWT decoder runs entirely in your browser and makes no network request — you can confirm it in the Network tab. It is still good practice to use a test token where one will do.
- Does decoding a JWT reveal the signing key?
- No. The signature is included in the token but the key that produced it is not. That is why decoding is safe and verifying is not something a client-side tool should be doing with your production secret.
- How do I check whether a tool uploads my input?
- Open devtools, go to the Network tab, clear it, then paste your input and run the tool. Any outbound request carrying your data is your answer.
Tools mentioned in this post
- JWT Decoder Decode a JWT and inspect its header, payload, and expiry. Tokens are decoded in your browser and never uploaded to a…
- Base64 Encoder & Decoder Encode text to Base64 and decode Base64 back to text, with URL-safe and UTF-8 support. Runs locally inside your…
- Certificate Decoder Decode PEM-encoded X.509 certificates and read subject, issuer, validity dates, SANs, and fingerprints. Runs locally…