Quick answer
Only with a browser-only decoder. A JWT is a credential, and its payload often identifies a live session, so pasting a production token into a server-based tool can leak it to a third party. The JSON Dev Tools JWT Decoder splits and decodes the token entirely in your browser — your token never leaves your device.
A JWT looks like a harmless string of gibberish, so developers paste them into the first online decoder they find. But a JWT is a live credential, its contents are readable by anyone, and decoding it tells you nothing about whether it's trustworthy. This guide covers what's actually inside a token, the real risk of pasting one into a server-based tool, and why decoding is not the same as verifying.
Key takeaways
- A JWT is not encrypted — anyone holding it can read its payload. Base64URL is encoding, not protection.
- A JWT is a credential. A valid, unexpired token can be used to impersonate whoever it represents.
- Decoding ≠ verifying. Decoding reads the claims; only signature verification proves they're authentic.
- Use a browser-only decoder so the token is never transmitted — like the JSON Dev Tools JWT Decoder.
What's actually inside a JWT?
A JWT (RFC 7519) has three Base64URL-encoded parts separated by dots: header.payload.signature. The payload is the part that matters for privacy — it carries the claims:
sub— the subject: the user ID this token represents.iss,aud— who issued the token and who it's for, often revealing internal infrastructure.exp,iat— when it expires and was issued.- Custom claims — frequently email, name, roles, permissions, tenant IDs, and other personal or organizational data.
Crucially, none of this is encrypted. Base64URL is reversible encoding that anyone can undo without a key. The signature doesn't hide the payload — it only proves the payload wasn't altered. So the contents of every JWT are fully readable by anyone who holds the token.
So what's the actual risk of decoding one online?
The risk isn't that a decoder "cracks" your token — it can't, and it can't reveal your signing secret either (the secret is never inside the token). The risk is simpler and more serious: a server-based decoder uploads your token to someone else's server.
If that token is a valid, unexpired production access token, you've just handed a working credential to a third party. Whoever controls that server can:
- Impersonate the user or service the token represents, until it expires or is revoked.
- Harvest the personal data in the payload — emails, names, roles, tenant info.
- Retain or log it indefinitely, outside your knowledge or control.
This is exactly the scenario behind real-world incidents where developers pasted live tokens into logging-enabled online tools. The token didn't need to be "hacked" — it was simply transmitted, stored, and later reused.
Decoding is not verifying — and this trips people up
This is the most important security concept around JWTs, and it's easy to miss:
| Decoding | Verifying | |
|---|---|---|
| What it does | Reverses Base64URL to read header + payload | Checks the signature against the issuer's key |
| Key required? | No — anyone can do it | Yes — the secret or public key |
| Proves authenticity? | No | Yes |
| Where it must run | Anywhere (do it client-side) | Server-side only |
A decoder showing you a clean, readable payload tells you nothing about whether the token is genuine. An attacker can craft a token with any claims they like and it will decode perfectly. Never trust a decoded claim for authentication — always verify the signature on your server first. An online decoder is an inspection tool, not a security check.
How to decode a JWT safely
- Use a browser-only decoder. Confirm the tool is client-side: load the JWT Decoder, turn off your network, and decode — it still works, because the token never leaves your browser.
- Prefer test tokens. When you can, decode a non-production token to inspect structure.
- If you must inspect a production token, only do it in a verified client-side tool — never one that transmits to a server.
- If you already pasted a live token into an untrusted tool, treat it as compromised: revoke or rotate it immediately.
For the broader question of pasting any sensitive payload into web tools, see is it safe to paste JSON into an online formatter? — the same browser-only-vs-server-based distinction applies.
Is the JSON Dev Tools JWT Decoder safe?
Yes. The JWT Decoder splits the token on its dots and Base64URL-decodes each part using JavaScript in your browser. Your token never leaves your device and is never uploaded to a server. It's also decode-only by design — it deliberately does not attempt signature verification, because that requires a secret that must stay server-side. (For transparency: the page records an anonymous page view via analytics, but that request never contains your token.)
Frequently Asked Questions
Is it safe to decode a JWT online?
Only with a browser-only decoder. A JWT is a credential, and its payload often identifies a live session, so pasting a production token into a server-based tool can leak it to a third party. A client-side decoder like the JSON Dev Tools JWT Decoder splits and Base64URL-decodes the token in your browser and never transmits it, which makes decoding safe.
Can anyone read the contents of a JWT?
Yes. A JWT is not encrypted — it is Base64URL-encoded, which is just reversible encoding, not protection. Anyone who has the token can decode and read the header and payload without any key. The signature only proves the token has not been altered; it does not hide the contents.
What is the difference between decoding and verifying a JWT?
Decoding reads the header and payload by reversing the Base64URL encoding — no key required, and it tells you nothing about whether the token is trustworthy. Verifying checks the signature against the issuer's secret or public key to prove the token is authentic and unaltered. You must verify server-side before trusting any claim; decoding alone is never sufficient for authentication.
What happens if I leak a production JWT?
If a valid, unexpired access token leaks, whoever holds it can impersonate the user or service it represents until it expires or is revoked. That is why you should never paste a production token into a tool that transmits it to a server. If you already did, treat the token as compromised and revoke or rotate it immediately.
Does decoding a JWT online expose the signing secret?
No. The signing secret or private key is never part of the token itself, so decoding cannot reveal it. The risk of an online decoder is not the secret — it is exposing the token (a usable credential) and the personal data inside its payload to a third-party server.
Decode a JWT privately — nothing transmitted
The JSON Dev Tools JWT Decoder runs entirely in your browser. Your token never leaves your device. Decode-only, no signup, works offline.