User Guide
Paste the token
A JWT is three Base64url sections separated by dots: header, payload and signature. Paste the whole thing including both dots.
Read the header
It names the signing algorithm (alg) and the token type. If alg reads none, treat the token as untrustworthy — that value has been used in real authentication bypasses.
Read the payload
This is the claims object: who the token identifies, what it permits, and when it expires. Check exp first — it is a Unix timestamp, and an expired token is the most common cause of a 401.
Understand what this tool does not do
It decodes. It does not verify the signature. A valid-looking decode proves only that the token is well formed, never that it is genuine.
Convert the timestamps
exp, iat and nbf are seconds since 1 January 1970. Paste them into the Timestamp Converter to read them as dates.
Never paste a live production token
Anyone holding a valid token can act as that user. Use an expired or test token when debugging, and rotate anything that has been shared.
About the JWT Decoder
A JSON Web Token, defined in RFC 7519, is a compact way to carry claims between services. This tool splits one apart and shows you the header and payload in readable JSON. It runs entirely in your browser.
The single most important thing about JWTs
A JWT is signed, not encrypted. Its contents are public.
The header and payload are ordinary Base64url — the URL-safe alphabet from RFC 4648. Anyone who obtains a token can read every claim inside it, on this page or in two lines of code. The signature does not hide anything; it only proves the token has not been altered since it was issued.
The consequence is a rule with no exceptions: never put anything confidential in a JWT payload. No passwords, no card details, no personal data beyond what the receiving service genuinely needs. Assume the payload will be read.
Decoding is not verifying
This tool does not check the signature, and that limitation is deliberate rather than an omission. Verification requires the secret or public key that signed the token — and pasting a production signing key into a web page would be a far worse idea than anything it could help you debug.
So a clean decode here tells you the token is well formed. It tells you nothing about whether it is genuine. Anyone can craft a JWT with any claims they like; only signature verification, performed server-side with the correct key, distinguishes a real token from a forged one. Never make an authorisation decision based on a decoded payload alone.
The three parts
| Section | Holds | Worth checking |
|---|---|---|
| Header | alg, typ, sometimes kid |
Whether alg is none |
| Payload | The claims | exp, iss, aud |
| Signature | Cryptographic proof of integrity | Verified server-side only |
Registered claims worth knowing: iss is the issuer, sub the subject (usually a user id), aud the intended audience, exp the expiry, nbf the not-before time, and iat when it was issued. The three time claims are Unix timestamps in seconds — note that JavaScript uses milliseconds, a factor of 1000 that causes a steady supply of bugs.
Debugging a rejected token
Check exp first. Expired tokens are the most common cause of an unexpected 401, and access tokens are often deliberately short-lived.
Then aud and iss. A token minted for one service and presented to another will fail validation even though it decodes perfectly.
Then nbf. A not-before time in the future makes a token invalid now but valid later, which produces confusing intermittent failures when server clocks drift.
Then the algorithm. If alg is none, or a token expected to be RS256 arrives as HS256, you may be looking at an attempted bypass rather than a bug.
Handling tokens safely
Treat a JWT the way you would treat the password it replaced. Anyone holding a valid token can act as that user until it expires. Use expired or test tokens when debugging, rotate anything shared in a ticket or chat, and keep tokens out of URLs and logs. For related work, the Base64 Decoder handles the URL-safe alphabet manually and the OWASP password storage guidance covers credential handling more broadly.
Privacy
Everything runs in JavaScript inside this page. Nothing you paste is transmitted, logged or stored — which is the reason it is safe to use on data you would not paste into a random website. Given what tokens grant access to, that is the minimum acceptable behaviour for a tool like this.
Frequently Asked Questions
Does this tool verify the token signature?
No, and that is deliberate. Verification requires the secret or public key that signed the token, and pasting a production signing key into a web page would be far more dangerous than anything it could help you debug. A clean decode proves the token is well formed, not that it is genuine.
Is the information in a JWT encrypted?
No. The header and payload are ordinary Base64url and anyone holding the token can read them. The signature proves the token has not been altered; it hides nothing. Never put confidential data in a payload.
Why is my token being rejected when it decodes fine?
Check exp first — expired tokens are the most common cause. Then aud and iss, since a token minted for a different service fails validation despite decoding perfectly. Then nbf, which can make a token valid only in the future if clocks have drifted.
What does alg: none mean?
That the token claims to need no signature. It has been used in real authentication bypasses, and any properly configured server rejects it. If you see it on a token you did not create, treat it as hostile.
How do I read the exp value?
It is a Unix timestamp in seconds since 1 January 1970. Paste it into the Timestamp Converter to see the date. Note that JavaScript works in milliseconds, so a factor of 1000 is a frequent source of bugs.
Is it safe to paste a real token here?
The decode happens entirely in your browser, so nothing is transmitted. Even so, use expired or test tokens as a habit — anyone holding a valid token can act as that user, and good practice does not depend on trusting any single page.
Can I create or sign a token here?
No. This tool only decodes. Signing requires a secret key, and any tool that asks you to paste one into a web page should be treated with suspicion. Generate tokens server-side with a maintained JWT library.
What is the difference between JWT and OAuth?
They solve different problems. OAuth 2.0 is a framework describing how an application obtains authorisation; JWT is a token format. OAuth often issues JWTs, but it can issue opaque tokens instead, and JWTs are used well outside OAuth.