JWT Decoder — Free JSON Web Token Inspector
Decode, inspect, and verify JSON Web Tokens instantly with deep claim analysis.
list_alt Claim Registry
| Claim | Description |
|---|---|
| iss | Issuer: Entity that issued the token |
| sub | Subject: The principal (user) of the token |
| aud | Audience: Intended recipients |
| exp | Expiration: Time token must no longer be accepted |
| iat | Issued At: Time token was created |
JWT Insights
Are my tokens sent to a server?
Why does it say 'Invalid Signature'?
What do the colors mean?
Reading a JWT Without Getting Fooled by It
The three parts of every token
A JWT is three Base64URL segments separated by dots — paste one above and they unfold:
| Part | Contains | Worth checking |
|---|---|---|
| Header | Algorithm (alg) and token type | alg: none or unexpected algorithm = red flag |
| Payload | Claims: sub, exp, iat, roles, custom data | exp (expiry) explains most 401 errors |
| Signature | Cryptographic seal over the first two parts | Can't be verified without the secret/key |
Decoding is not verifying — the critical difference
Anyone can decode a JWT; that's by design — the payload is readable, not secret. What the decoder cannot tell you is whether the token is authentic: that requires checking the signature against the issuing server's secret or public key. Two consequences follow. Never put sensitive data in a JWT payload (it's effectively plaintext), and never trust client-side decoding for authorization decisions — a tampered payload decodes just as cleanly as a real one.
The debugging routine
API suddenly returning 401? Decode the token and read exp — expired tokens are the cause nine times out of ten. Role missing from a permissions check? Look at the actual claims rather than what the docs promise. Decoding here happens in your browser, which matters: production tokens pasted into a server-side tool are credentials handed to a stranger. The raw segments are plain Base64 if you want to inspect them manually, and signature hashes relate to the SHA-256 generator.