JWT Decoder
Decode JWT tokens to view header and payload data
Choose a Tool
Decode JWT tokens to view header and payload. Optionally verify the signature with a secret key. All processing happens locally in your browser - no data is sent to any server.
How to decode a JWT
Paste a token and read what's inside. A secret is only needed if you also want to check the signature.
- 01
Paste the token, with or without "Bearer"
Copy the Authorization header value from your browser's Network tab, Postman or a log line. A leading "Bearer " is stripped before decoding, so you don't need to trim it by hand.
- 02
Decode and read the header and payload
The tool splits the token at its two dots, base64url-decodes the first two parts and shows them as JSON. The header tells you the algorithm; the payload holds the claims.
- 03
Add the secret only if you want to check the signature
Decoding needs no key. If the token is HS256, HS384 or HS512 and you know the secret, enter it and press Verify Signature to confirm nothing was changed.
Why every JWT starts with eyJ
A signed JWT is three base64url strings joined by dots: header, payload and signature. Base64url is plain encoding, not encryption, so anyone holding the token can read the first two parts. That's exactly what this decoder does.
The header and payload are JSON objects, and JSON objects start with {". Encode those two characters plus the next one in base64 and you always get eyJ. So if a string starts with eyJ and has two dots, it's almost certainly a JWT. The classic example header, {"alg":"HS256","typ":"JWT"}, encodes to eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
The registered claims you'll see most
RFC 7519 defines seven short claim names. None is required, but most identity providers use several of them. Anything else in the payload, such as email, role or a tenant ID, is a custom claim set by whoever issued the token.
| Claim | Name | What it holds |
|---|---|---|
| iss | Issuer | Who created the token, often your auth server's URL |
| sub | Subject | Who it's about, usually a user ID |
| aud | Audience | Which API or app should accept it |
| exp | Expiry | Unix time in seconds after which it's invalid |
| nbf | Not before | Unix time before which it's not valid yet |
| iat | Issued at | Unix time when it was created |
| jti | JWT ID | A unique ID, used to block replays or revoke one token |
The decoder shows exp, nbf and iat as the raw numbers in the token. To read one, paste it into the Unix Timestamp Converter: 1735689600, for example, is 1 January 2025 at 00:00 UTC. If the number has 13 digits, it was written in milliseconds by mistake, and most servers will treat the token as expiring tens of thousands of years from now.
When decoding a token helps
Working out why an API returns 401
Decode the token your app sent and check the aud, iss and exp values against what the API expects. A wrong audience is a frequent cause.
Checking what an identity provider puts in
Auth0, Cognito, Firebase and Supabase all add their own claims. Decoding a real token shows the exact names before you write code that reads them.
Confirming a role or scope change
After changing a user's permissions, decode a fresh token to see whether the new role is in it, or whether the old token is still being used.