Decode any JSON Web Token entirely in your browser and inspect exactly what it claims. The header and payload are pretty-printed, every registered claim is translated into readable UTC time, and dangerous conditions such as alg:none or an expired token are flagged.
How to use it
- Paste a complete token, including all three dot-separated segments.
- Read the decoded header to see the signing algorithm and token type.
- Read the decoded payload to see the claims the token asserts.
- Check the highlighted timestamps and warnings before trusting anything the token says.
Paste tokens from your own systems or test environments. A production access token is a live credential, so treat it with the same care as a password even though this page never transmits it.
What the registered claims actually mean
A JWT is three Base64url segments: header, payload and signature. The payload carries claims, and seven of them are registered in RFC 7519. iss names the issuer that minted the token and aud names the audience meant to accept it, which together stop a token issued for one service being replayed against another. sub identifies the principal, usually a user ID. exp is the expiry and nbf the not-before time, both Unix timestamps that this decoder renders as human-readable UTC so you can immediately see whether a token is live. iat records when it was issued, useful for spotting tokens with absurdly long lifetimes. jti is a unique ID that supports replay detection and revocation lists.
The alg:none trap
The JWT specification permits an algorithm value of none, meaning the token is unsigned. A library that honours the header without checking it against an expected algorithm will happily accept a token an attacker forged with the signature stripped. A related flaw is algorithm confusion, where a token signed with RS256 is swapped for an HS256 token and the server verifies it using the public key as if it were a shared secret. Both are why this decoder highlights the header algorithm prominently, and why servers must pin the algorithm they expect rather than trusting the token to declare it.
Frequently asked questions
Does this verify the signature?
No, deliberately. Verifying would require you to paste the signing secret or private key into a web page, which is exactly the habit security tooling should not encourage. This is an inspector: it shows you what a token contains and whether its timing and algorithm look sane. Signature verification belongs in your application or in a local, trusted library.
Anyone can read my token payload?
Yes. Base64url is encoding, not encryption, so every claim in a JWT is readable by anyone holding the token. Never put passwords, API keys, or personal data you would not want disclosed into a payload. The signature protects integrity, not confidentiality.
Is my token sent to your server?
It is not. Decoding happens entirely in your browser, and the token never leaves the tab. Nothing is logged, stored, or transmitted.
Related tools: Base64 Encoder / Decoder, Unix Timestamp Converter, Hash Analyzer.