JWT Decoder (Read a Token)
See a JWT's header and payload as formatted JSON; exp and iat claims are converted to readable dates
Your data stays with you. Conversion happens inside the browser; nothing is sent to a server.
Did this tool do the job?
Thanks, your feedback came through.
How it works
Paste the token into the left pane exactly as you copied it; if a Bearer or Authorization: prefix came along, the tool strips it, and tokens broken across lines are joined back together. The output shows three blocks: the header (algorithm and type), the payload (the claims the token carries) and the time claims. For example, a payload containing "exp": 1817121600 is annotated with the matching calendar date and whether that moment has already passed; iat (issued at) and nbf (not valid before) are converted the same way. The token is never sent to a server, which is why inspecting a real token from a system you are logged into is safe. What this tool deliberately does not do is verify the signature: reading the content proves nothing about its integrity — verification requires the secret key, and a secret key should never be pasted into any web page.
This tool is also known as jwt decoder, decode jwt online, jwt decode, read jwt token, jwt expiration check.
What is JWT (JSON Web Token)?
A JWT is a three-part text format for carrying identity and authorisation data between two systems: the header names the algorithm, the payload carries the claims, and the signature proves the content was not altered. The parts are separated by dots and each is Base64URL-encoded — so the content is packaged, not encrypted. After login, a server hands the user a JWT; on later requests it recognises the user by verifying the signature instead of querying a database. That design makes the token portable, at a price: whoever holds the token can act as that identity until it expires.
What is Base64URL?
Base64URL is an encoding that maps data onto a safe alphabet of letters, digits, hyphens and underscores; the + and / of classic Base64 carry special meaning in URLs, so they are replaced by - and _, and the trailing = padding is dropped. All three parts of a JWT use this encoding, which is why a token survives intact in an address bar, a cookie or an HTTP header. Encoding is not encryption: any tool can reverse it without a key — which is exactly what this page does.
What is the difference between decoding and verifying a JWT?
Decoding means reversing the Base64URL encoding and reading what the header and payload say; it needs no key, anyone can do it, and that is what this tool does. Verifying means computing whether the signature, the content and the secret key agree: change one character of the content, or sign with a different key, and verification fails. The difference is critical for security — a decoded token only tells you what is being claimed, while a verified token proves the claim was signed by a party holding the key. On the server side, decoding alone is never enough; the signature must be verified on every request.
Do not trust decoded content: the signature was not checked
The first two parts of a JWT are not encrypted, only Base64URL-encoded; that encoding is an envelope, not a lock, and anyone can open it. A token's trustworthiness comes from the third part, the signature — a mathematical digest of the content and a secret key, which only a party holding the key can verify.
This tool skips verification on purpose, because doing it here would mean pasting your secret key into a web page — and a production key must never be pasted into any website, this one included. What you see here answers 'what does the token claim'; only your server, checking the signature against the key, can answer 'is this token genuine'.
What do the payload claims mean?
RFC 7519 standardises a handful of claim names; everything else is application-specific. These are the ones you will meet most often:
- sub → the subject of the token (usually the user ID)
- iss → the system that issued the token (issuer)
- aud → the system the token was issued for (audience)
- exp → expiry moment; after this the server rejects the token
- iat → when it was issued; the gap to exp is the token's lifetime
- nbf → not valid before this moment (used in post-dated tokens)
Frequently asked questions
How do I decode a JWT?
Paste the token into the left pane — that is all. The header and payload open as formatted JSON instantly, and time claims such as exp and iat are converted to readable dates. No setup, no key required.
Is my token sent to a server?
No. Decoding runs entirely inside your browser and the token is never transmitted anywhere. Still, be careful: a production token that has not expired grants a session to whoever holds it — close the page when you are done.
Does this tool verify the signature?
No, deliberately not. Verification requires the secret key, and secret keys should never be pasted into a browser page. The tool only shows the content; whether the token was really issued by your server is something only your server can confirm.
How do I tell whether the token has expired?
If the payload carries an exp claim, the tool converts it to a date and writes next to it whether it has expired or not. The comparison uses your computer's clock — if that clock is wrong, so is the verdict.