JWT decoding happens entirely in your browser. Your token is never uploaded or stored.
What is a JWT?
A JSON Web Token is a compact, signed statement. Someone — an identity provider, an API, your own login endpoint — writes down some facts as JSON, signs them, and hands the result over. Anyone who trusts the signer can then check those facts without asking the signer again.
That last part is the point. A session id means a lookup on every request; a JWT carries its own proof, so a service can accept it with nothing but a key. It is what makes JWTs fast, stateless and awkward to revoke — all for the same reason.
The critical thing to understand before using one: a signed JWT is not encrypted. The payload is base64url, which is an encoding, not a cipher. Anyone holding the token can read every claim inside it — this page does exactly that, in your browser, with no key at all.
JWT structure explained
Three base64url segments separated by full stops. You can spot one by eye: it almost always starts eyJ, which is what {" encodes to.
Says how the token was signed. alg names the algorithm and typ is normally JWT. A kid often appears too, telling the verifier which of several keys to use.
The payload
The claims — the actual statement. Registered claims such as sub and exp mean the same thing everywhere; everything else is defined by whoever issued the token. Keep it small: the token travels on every request.
The signature
The header and payload, joined with a dot, run through the algorithm with a key. Change a single character of either and the signature no longer matches. That is the entire security model — and it only works if somebody actually checks it.
Standard JWT claims
RFC 7519 registers these seven. They are all optional, but they mean the same thing in every system, which is what makes a token from one provider readable by another.
issIssuer
Who created and signed this token.
subSubject
Who the token is about — usually a user id.
audAudience
Who the token is intended for. A recipient should reject a token not addressed to it.
expExpiration
After this moment the token must be rejected.
nbfNot before
Before this moment the token must be rejected.
iatIssued at
When the token was created.
jtiJWT ID
A unique id for this token, used to prevent replay.
exp, nbf and iat are Unix timestamps in seconds, not milliseconds. Multiplying by a thousand is the most common bug in JWT code, and it produces expiry dates in the year 56000. When a number needs turning into a date you can read, drop it into the Unix timestamp converter.
How JWT decoding works
There is not much to it, which is rather the point.
1. Split on the full stops. Three parts means a signed token (JWS); five means an encrypted one (JWE), which cannot be read without a key.
2. base64url-decode the first two. base64url swaps +/ for -_ and drops the padding. The Base64 decoder accepts that variant as it stands, so a single segment pasted on its own decodes without any fixing up.
3. Parse the result as JSON, as UTF-8. Now you have the header and the payload.
4. Leave the signature alone. It is bytes, not text, and nothing can be learned from it without the key.
No key, no network, no permission required. That is why this page can do it entirely in your browser — and equally why decoding proves nothing.
JWT decoding vs JWT verification
These get conflated constantly, and the confusion is how forged tokens get accepted. They are different operations answering different questions.
Decoding
“What does this say?”
Needs no key
Anyone holding the token can do it
Reveals every claim
Proves nothing about who issued it
Safe to do in a browser — this page
Verification
“Is this genuine?”
Needs the secret or the public key
Only the intended verifier can do it
Establishes the token was issued by whom it says
Establishes it has not been altered since
Belongs on your server, never in a web page
This tool decodes. It does not verify, and it never will. Verification needs the signing key, and a page that asked you to paste a production secret would be asking you to leak the one thing that makes the whole scheme work. Use your language’s JWT library on the server for that.
So treat everything on this page as what the token claims, not as fact. A token can say "role": "admin" because an administrator issued it, or because somebody typed it. Only a signature check tells the two apart.
Common JWT use cases
Authentication
After a successful sign-in the server issues a token, and the browser sends it with each request instead of the password. The server checks the signature rather than looking anything up.
Authorization
Roles and permissions travel in the payload, so a service can decide what a request may do without asking a user database.
OAuth 2.0
Access tokens are frequently JWTs, carrying the scopes granted and the client they were issued to.
OpenID Connect
The ID token is a JWT by definition, and adds identity claims: who the user is, when they authenticated and which application asked.
REST APIs
A bearer token in the Authorization header is the default way to authenticate a request, and it is usually a JWT.
Single sign-on
One identity provider signs a token that several applications accept, so a user signs in once and every service trusts the same signature.
Service to service
Short-lived signed tokens let one internal service prove its identity to another without shared passwords.
JWT security best practices
Never share a production token. A JWT is a credential. Posting one in a ticket, a chat or a support request hands over whatever it authorises until it expires. Redact the payload, or mint a throwaway token in the JWT generator, when asking for help — including on this page, which is why every sample here is fabricated.
Keep expiry times short. A JWT usually cannot be revoked, so its lifetime is how long a stolen one stays useful. Minutes for access tokens, with a revocable refresh token behind them.
Always verify the signature — and pin the algorithm.Decide server-side which algorithm you accept rather than trusting the header’s alg. Reject none outright. Trusting the header is how the classic algorithm-confusion attack works.
Check the claims, not just the signature. A validly signed token can still be the wrong one: confirm iss is who you expect, aud is you, and exp and nbf allow it now.
Put nothing secret in the payload. It is readable by anyone holding the token. No passwords, no card numbers, no personal data you would not print on a postcard.
Store it carefully. localStorage is readable by any script on the page, so one cross-site scripting flaw becomes a stolen session. An httpOnly, Secure, SameSite cookie keeps it out of JavaScript entirely.
Send it only over HTTPS. A bearer token is a password in transit. Anyone who intercepts it can use it.
Frequently asked questions
Is this JWT Decoder free?
Yes. Decoding, the claims inspector, expiry analysis, search, copy and download are free, with no account and no limit on how many tokens you inspect.
Is my token uploaded?
No. The token is decoded by JavaScript running in your browser. Nothing is sent to a server, nothing is stored and nothing is logged. You can disconnect from the network after the page loads and it keeps working. That matters more here than on most tools: a JWT is a credential, and pasting one into a page that transmits it would be handing someone your session.
Can this verify signatures?
No, and that is deliberate. Verifying a signature requires the issuer's secret or public key, and pasting a production signing secret into a web page is exactly the mistake this tool's own advice warns against. Everything here describes what the token says; nothing here says whether the token is genuine.
What is the difference between decoding and verifying?
Decoding is reading. A JWT's header and payload are base64url — an encoding, not encryption — so anyone holding the token can read every claim in it, and this tool does exactly that. Verifying is checking the signature against the issuer's key to establish that the token was really issued by them and has not been altered since. Only verification tells you anything about authenticity, and it can only happen on a system that holds the key.
Is a JWT encrypted?
A signed JWT is not. Base64url looks scrambled but is trivially reversible, so never put anything secret in a payload — no passwords, no card numbers, nothing you would not print on a postcard. There is an encrypted variant, JWE, which has five parts instead of three; this tool recognises one and says it cannot be read without the key.
Can I decode expired tokens?
Yes. Expiry is a claim inside the payload, not something that stops it being readable, so an expired token decodes exactly like a live one. The tool reads the exp claim and tells you when it lapsed and how long ago.
What are JWT claims?
The name–value pairs in the payload. RFC 7519 registers seven that mean the same thing everywhere — iss, sub, aud, exp, nbf, iat and jti — and anything else is a custom claim defined by whoever issued the token. The tool marks which is which and explains what each registered one means.
Does this support HS256 and RS256?
It reads any algorithm, because decoding does not depend on the algorithm at all — the header and payload are base64url whatever signed them. So HS256, HS384, HS512, RS256, ES256, PS256 and EdDSA tokens all decode here. What it does not do is check the signature for any of them.
What does alg: none mean?
An unsecured JWT, defined in RFC 7519 §6 — it carries no signature at all. It is also the shape of a classic attack: take a real token, strip the signature, set the algorithm to none, and a verifier that trusts the header accepts it. The tool flags these prominently. Production systems should reject them outright rather than trusting the header to say which algorithm to use.
Can I download the decoded payload?
Yes. The header and payload can each be downloaded as JSON from their own panel, and the toolbar's download button saves a complete analysis: header, payload, signature, expiry status and statistics, with a note recording that the signature was not verified.
Why does my token fail to decode?
Almost always truncation — tokens are long and easy to cut short when copying. The tool says which of the three parts is wrong and why: too few parts, characters that base64url does not allow, or JSON that does not parse. A token pasted with a Bearer prefix or wrapped in quotes is handled automatically.
What is the nbf claim?
Not before: the moment a token starts being valid. A token with an nbf in the future must be rejected until then, which is how a system issues credentials ahead of time for a scheduled job or a future session. The tool reports a token in that state separately from an expired one.
How long should a token live?
As briefly as the application can tolerate. Fifteen minutes to an hour is common for access tokens, with a longer-lived refresh token that can be revoked. The reason is that a JWT usually cannot be cancelled once issued — the whole point is that a verifier does not need to ask anyone — so a stolen token stays useful until it expires.
Where should I store a JWT?
Not in localStorage, if it can be avoided: any script on the page can read it, which turns one cross-site scripting flaw into a stolen session. An httpOnly, Secure, SameSite cookie is safer, because the browser will not hand it to JavaScript at all. Whatever you choose, always over HTTPS.
Can a JWT be revoked?
Not on its own. A verifier checks the signature and the claims without consulting the issuer, which is what makes JWTs fast and stateless — and also means there is nowhere to mark one as cancelled. Real systems handle this with short lifetimes plus a deny-list of jti values, or by keeping the revocable part in a refresh token.
Are there keyboard shortcuts?
Ctrl/Cmd+Enter decodes, Ctrl/Cmd+Shift+C copies the current panel, Ctrl/Cmd+Shift+D downloads the analysis, Ctrl/Cmd+Shift+L loads the next sample token and Ctrl/Cmd+Shift+Delete clears the input. Ctrl/Cmd+F opens the search, and Escape closes it.
Keep going
Tools that pair with this one
Same privacy model — everything below runs in your browser too.
