JWT
JWT Decoder
Decode a JSON Web Token's header and payload.
About JWTs
A JSON Web Token packs a header, a payload, and a signature into three Base64URL-encoded segments joined by dots. The header and payload are just encoded JSON, so anyone can read them, while the signature is what actually proves the token wasn't tampered with.
The header's alg field names the signing algorithm, but because the header is just decoded, unverified JSON, a client cannot trust it to say anything true — a well-known class of JWT vulnerability involves an attacker changing alg to "none" and stripping the signature, hoping a careless verifier accepts an unsigned token. Real verification must check the signature against a specific algorithm and key that the verifying server chose itself, never one read out of the token. The payload's exp and iat claims are Unix timestamps (seconds since epoch, not milliseconds) — pair this tool with the Timestamp Converter to read them as calendar dates.
Where you'll run into it
- Inspecting an access or ID token issued by an OAuth or OIDC provider
- Debugging why a token is missing an expected claim
- Checking a token's expiry or issuer without writing code
- Understanding what a third-party API or library puts inside its tokens
Frequently asked
Does decoding verify the signature?
No — this only decodes the header and payload so you can read them. It doesn't check the signature, so a decoded token isn't proof that it's genuine or unexpired.
Can I trust the claims in a token I haven't verified?
Not for security decisions. Anyone can craft a JWT with arbitrary claims; only a verified signature, checked against the issuer's key, makes the contents trustworthy.
Is the token I paste here stored?
No. Decoding happens entirely for that one request; nothing is logged or kept.
Can the header's alg field be trusted?
Not on its own. The header is unverified, attacker-controlled JSON as far as anyone reading a raw token is concerned — a known JWT attack sets alg to "none" and removes the signature entirely, hoping a verifier that blindly trusts the header will accept it as valid. Correct verification code hard-codes which algorithm and key it expects and never takes that decision from the token itself. This tool only decodes for reading; it makes no trust decisions at all.