JWT Decoder
Paste a token and read what is inside it. Nothing is sent anywhere — which matters more for this tool than for most, because a token is often the key to somebody's account.
How to use it
- Paste the token. It is the long string with two full stops in
it, often sent as
Authorization: Bearer …. - Read the header and payload. Any date-like claim is also printed in words underneath.
A token is not encrypted. It is only encoded.
This surprises people, and it is the single most important thing to understand about JWTs. The middle section of a token is ordinary Base64 text. Anybody holding the token — a browser extension, a log file, someone reading over your shoulder — can read every claim inside it without any key at all. This page is not breaking anything; it is doing what any two lines of code can do.
So never put anything in a JWT that the holder should not see. No internal notes, no other people's details, no secrets. The signature stops the token being altered. It does nothing to stop it being read.
This page does not verify the signature, on purpose
Verifying would mean you typing the server's secret key into a website. That is a worse idea than anything this page could tell you, and no honest tool should ask for it. So the signature is shown as present or absent and nothing more.
Which means: a token that decodes here is not a valid token. It is a well-formed one. Anyone can write any claims they like, encode them, and this page will display them neatly. Only your server, holding the key, can say whether a token is real.
Two things worth checking by eye
If the header says "alg": "none", be suspicious. It is
a legitimate part of the specification and also the shape of a
classic attack, where a token is stripped of its signature and
handed to a server that forgets to insist on one.
And the time claims — exp, iat,
nbf — are counted in seconds since 1970,
not milliseconds. Code that mixes the two is the most common JWT bug
there is, and it fails in a memorable way: a token that expires in
the year 56000, or one that expired before it was issued.
Should you paste a real token anywhere?
Not as a habit. This page reads the token in your own browser and sends nothing, so it is safe here. But most decoders on the web look exactly like this one and you cannot tell from the outside which ones post your token to a server. A live token is usually enough to act as you. Use an expired one, or a test one, when you can.
Frequently asked questions
Is my token sent anywhere?
No. It is split and decoded by JavaScript in your own browser and nothing is uploaded. That is worth caring about here more than on most pages, because a live token often grants access to an account.
Why does it not check whether the token is valid?
Because checking the signature needs the server's secret key, and no website should ever ask you to type that in. The page tells you what the token says; only your server can tell you whether it is genuine.
Can I edit the payload and re-sign it?
Not here, and that is deliberate. Changing a claim breaks the signature, and producing a new valid signature requires the key. A tool that offered it would be asking for your key.
Why is the expiry date wrong by decades?
Almost always because something wrote milliseconds where the specification says seconds, or the other way round. The claims exp, iat and nbf are all in seconds since 1970.
What does 'alg: none' mean?
It means the token carries no signature. It is part of the standard, and it is also how a well-known attack works - strip the signature and hope the server accepts it. If you see it on a token that should be signed, that is worth investigating.
Is my text sent anywhere?
No. Everything happens in JavaScript inside your own browser. Nothing is uploaded and nothing is saved - close the tab and it is gone.