JWT Decoder

What a JWT is

A JSON Web Token has three parts separated by dots: header, payload and signature. The first two are JSON encoded in URL-safe Base64 — readable by anyone, not encrypted. The third is the signature, which lets whoever holds the key verify that the first two have not been altered.

The payload is not secret

This is the most common misunderstanding. A JWT hides nothing: anyone who intercepts it can read its contents without any key, exactly as this tool does. The payload should therefore never carry confidential data — only what you are willing to show to whoever holds the token.

The timestamps, which is why you are here

The exp, iat and nbf claims are seconds since 1 January 1970: unreadable at a glance, and exactly what you go looking for when a token "stopped working". They are shown here in readable form too, with how long remains before expiry or how long ago it passed.

Why the signature is not verified

Verifying it would require the key — the secret that must not circulate. Pasting it into an online tool would defeat the security of the whole system. A token decoded without verification therefore tells you what it claims, not whether those claims are genuine. For verification, use a library inside your own code, where the key already lives.

How to use it

Paste the token into the box and the header and payload appear in plain text, with the time claims already converted into readable dates. There is nothing to send and nothing to configure: decoding is pure reading, and it happens in the browser.

When it comes in handy

The moment an authentication "stopped working" and the token looks identical to yesterday's: exp and iat immediately say whether it expired or was issued by a skewed clock. Then integration debugging — reading what the token two systems exchange really contains — and teaching: a few concrete examples explain the structure better than any diagram.