JWT Decoder — decode a JSON Web Token

What a JWT actually contains

Three parts separated by dots: a header, a payload and a signature. The first two are JSON, base64url-encoded — not encrypted, not compressed, not obscured in any way. Anyone holding the token can read them, which is why a JWT should never carry a password, a card number or anything else you would not put in a log line.

Why this page does not verify the signature

Decoding is not decryption, and it is not validation either. The signature proves the token was issued by someone holding the signing key and has not been altered since — checking it requires that key. Pasting a signing secret into a web page is a bad habit even when the page is honest, so this one does not ask for it and cannot check the signature. Verify tokens in your own code, with your own key.

That means the status above describes the claims, not the token's authenticity: an expired token is definitely not usable, but an unexpired one is only usable if its signature also checks out.

Non-ASCII claims, and why they are usually broken

The browser's built-in atob returns latin1, so a decoder written the obvious way turns a name like José into José and an emoji into nonsense — silently, with no error. This page decodes the bytes as UTF-8, so a payload containing any non-English text reads correctly.

Tokens are credentials, so where you paste them matters

A JWT from a live system is a bearer credential: whoever holds it can act as you until it expires. Every decoder that sends the token to a server has, for a moment, had your credential in its logs. This one does not have that moment — the decoding runs in the page, and no request this page makes ever carries the token. You can confirm that by watching the network tab for the token itself, or by disconnecting from the network and watching decoding keep working.

If the payload turns out to be malformed JSON, the JSON validator gives the line and column, and the JSON error reference explains the message.