A JWT is three separately encoded parts, not one encrypted blob
A JSON Web Token is three Base64URL-encoded segments joined by dots: header.payload.signature. The header and payload aren't encrypted — they're just encoded, which means anyone can decode and read them with nothing more than a Base64URL decoder. There's no secret required to see what's inside a JWT; the secret only comes into play for the third part, the signature, which is what actually proves the token wasn't tampered with.
This is the single most important thing to understand about JWTs and the reason this tool explicitly separates decoding from verification: decoding tells you what a token claims, verification tells you whether those claims can be trusted. They are not the same operation, and a tool (or a person) that treats successful decoding as proof of authenticity is making a serious security mistake.
What decoding tells you vs. what verification tells you
| Question | Answered by decoding | Answered by verification |
|---|---|---|
| What claims does this token contain? | Yes | Yes |
| What algorithm does the header specify? | Yes | Yes |
| Was this token issued by the claimed issuer? | No | Yes |
| Has the payload been tampered with since signing? | No | Yes |
| Should this token be trusted for authentication? | No | Yes (if verification passes) |
Decoding a token
Paste your JWT (three dot-separated Base64URL parts) into the tool.
The header and payload are decoded and pretty-printed automatically as JSON.
Copy either section, or the signature, as needed.
Why verification can't happen in a tool like this
Verifying a JWT means recomputing the signature using the algorithm named in the header and comparing it against the token's actual signature — which requires the issuer's secret key (for HMAC algorithms like HS256) or public key (for RSA/ECDSA algorithms like RS256, ES256). A general-purpose decoding tool has no way to know or safely hold that key; asking users to paste a private signing secret into a browser tool would be a worse security practice than the problem it solves. That's why decoding here is deliberately algorithm-agnostic: it Base64URL-decodes the header and payload regardless of which algorithm is named, without attempting to validate anything.
Reading the header field that matters most
Inside the decoded header, the `alg` field is worth checking specifically: a value of `none` means the token is explicitly unsigned. Some libraries historically accepted `alg: none` tokens as valid due to implementation bugs, which became a well-known JWT vulnerability class — a token with no signature should never be trusted for authentication under any circumstances, no matter what its payload claims.
Common mistakes
Treating successful decoding as proof a token is legitimate — decoding only shows what's claimed, never whether it's true.
Pasting a production access token into any web-based decoder as a debugging habit — even though decoding runs locally here, treat live authentication tokens the same way you'd treat a password and prefer a local script when possible.
Assuming a 'not JSON' badge on the payload means the token is broken — it can also mean a custom or non-standard token format that intentionally doesn't follow the typical JSON claims structure.
Confusing an expired token with an invalid one — decoding will happily show you an `exp` claim in the past; the tool doesn't evaluate it, so checking expiry is on you.
Real use cases
Debugging why an API call is failing by inspecting exactly which claims (roles, expiry, audience) a token actually carries.
Checking that a backend service is issuing tokens with the expected claim structure during development.
Confirming a token's algorithm and expiry before writing server-side verification logic against it.
Inspecting a third-party token's payload structure to understand an unfamiliar API's authentication scheme.
Frequently asked questions
Q: Does this tool verify the JWT signature?
A: No. Decoding shows the token's contents, but anyone can craft a token with any payload they like. To verify, you must validate the signature against the issuer's secret or public key on a trusted server.
Q: What algorithms are supported?
A: Decoding is algorithm-agnostic — it simply Base64URL-decodes the header and payload regardless of which algorithm is named. Verification, which this tool doesn't perform, would require knowing and using that specific algorithm.
Q: Why does my payload show 'not JSON'?
A: The header and payload are expected to be JSON. If they aren't, the tool still shows the raw decoded text with a small 'not JSON' badge — this can happen with malformed or custom, non-standard tokens.
Q: Can I decode tokens with no signature?
A: Yes — if the third part is missing, the signature shows '(none)'. Unsigned tokens (alg: none) are insecure and should never be trusted for authentication.
Q: Are my tokens uploaded anywhere?
A: No, decoding happens entirely in your browser — but still avoid pasting production access tokens into any web tool as a habit, and prefer a local script for live credentials when possible.
Q: The payload shows an 'exp' claim in the past — does that mean the tool flags it as expired?
A: No. The tool decodes and displays claims as-is without evaluating them; checking whether a token is expired, and rejecting it if so, is logic that has to happen wherever the token is actually being verified.
Decode a token now
Inspect your token with the JWT Decoder. For the raw JSON structure underneath, pretty-print it with the JSON Formatter. Need to work with the encoding itself? Try Base64 Encode / Decode, or generate a hash for comparison with the Hash Generator.
