Free JWT Decoder
Reading a token while debugging a login problem
Most people open a JWT decoder because something is not working: a user is logged out unexpectedly, an API returns an unauthorised error, or a token that should be valid is rejected. A JSON Web Token looks like a random string, but its first two parts are just encoded JSON, so with the right view you can usually see what is wrong in seconds. This decoder shows the header and payload as formatted JSON, turns timestamps into dates, says whether the token has expired, and can check an HMAC signature against a secret. It all runs in your browser.
A guided tour of a decoded token
Take a token whose payload reads: subject 42, issued at a Tuesday morning, expires an hour later, audience the mobile app. The decoder would show a status badge such as Expires in 43 minutes, and list the dates in UTC and in your own time. You see at a glance who the token is about, when it was issued, when it stops working and who it is meant for. The header tells you the signing algorithm, such as HS256.
Claims worth checking first
- exp. The expiry time. An expired token is the single most common cause of unexpected logouts.
- iat and nbf. When the token was issued and the earliest time it is valid. If nbf is in the future, clocks on two systems probably disagree.
- aud. Who the token is for. A token issued for one service will be refused by another.
- iss. Who issued it. Your API may accept tokens only from a specific issuer.
- sub. The subject, usually a user identifier.
- alg. The algorithm. A value of none means the token is unsigned, which a server should never accept.
Clock trouble
The expiry badge compares the exp claim with your own device clock. If your clock is wrong, so is the answer. In real systems, small differences between servers also cause issues, a token issued by one server may appear to be from the future to another, and many systems allow a little leeway, often a minute or so, to absorb that. If tokens fail only near their start or end time, clock drift is a likely suspect.
Checking a signature
For tokens signed with HS256, HS384 or HS512, type the shared secret and click Check signature. The tool recalculates the signature in your browser and tells you whether it matches. A match proves the token was signed with that secret and has not been changed. A mismatch means a different secret, a changed token, or a secret that is stored in a different form, so try the base64url option if your system keeps it encoded. Tokens signed with RSA or ECDSA need a public key to verify, which this tool does not handle.
What a JWT does not protect
A common misunderstanding is that a token’s contents are secret. They are not. The payload is only encoded, so anyone who holds the token can read it, exactly as this tool does. Never put passwords or sensitive personal details in it. The signature protects the token from being changed, not from being read. And decoding does not prove a token is genuine: anyone can create a token that decodes perfectly. Only a signature you can verify, together with sensible checks of expiry, issuer and audience, makes a token trustworthy.
Common token mistakes seen in real projects
- Using the same secret in development and production.
- Setting the expiry far in the future, for convenience.
- Putting too much user data in the payload.
- Accepting tokens without checking the audience.
- Storing tokens where scripts from other sources can read them.
Handle live tokens with care
A live token may grant access to an account or an API until it expires. Decoding here is done in your browser and nothing is sent anywhere, but as a habit, prefer test tokens for experiments, never paste live production tokens into forums or chats, and rotate any token that has been exposed. When you need to inspect the encoded parts by hand, the Base64 decoder does the same job step by step, and the JSON formatter tidies the output.
FAQ
Paste it into the box above. The header and payload appear as formatted JSON, with dates and expiry explained.
Yes. The header and payload are only Base64url encoded. The signature protects against changes, not against reading.
Look at the expiry badge, which compares the exp claim with your device’s current time.
No. It checks HS256, HS384 and HS512 signatures with a shared secret.
No. Decoding and verification run in your browser.
Either the secret is different, the token was changed after signing, or the secret is stored in another form, such as base64url. Try that option before assuming the token is bad.