JWT Decoder
Header
Payload
The standard claims
Signature
What a JWT actually is
Three Base64 chunks joined by dots: a header saying how it was signed, a payload of claims, and a signature over the first two. The signature stops anyone changing the contents. It does nothing to stop them reading the contents — which is the point most people miss.
What not to put in one
- Passwords, card numbers, anything you would not print on a postcard.
- More personal data than the receiving service actually needs.
- Anything you would be unhappy to see in a browser history or a log file.
Why this page will not verify for you
Verification needs the signing key. Any page offering to check a signature is asking you to paste that key into someone else's website — and a leaked signing key lets an attacker mint tokens for any user. Verify on your server.
Share this tool with friends
Free to use, no sign-up, works on any phone.
Frequently Asked Questions
No, and this is the thing people get wrong most often. The header and payload are only Base64-encoded, which anyone can reverse — including this page. Never put a password, a card number or anything private in a token.
No, deliberately. Verifying needs the secret or public key, and pasting a signing secret into a web page is exactly the habit that gets systems breached. Verify on your server, where the key lives.
exp is when it expires, iat when it was issued, nbf the earliest it may be used, iss who issued it, sub who it is about and aud who it is for. All the times are Unix seconds, which this page converts for you.
Usually expiry or a clock difference of a few seconds between machines. Check exp against the real time here, and remember nbf can also make a token too early rather than too late.
No. It is split and decoded in your browser and never transmitted. Even so, treat any token you paste anywhere as compromised and rotate it if it is a live one.