JWT Decoder

How to use the JWT decoder

1. Paste a JSON Web Token, the long string that usually follows Authorization: Bearer.
2. The header and payload are decoded and shown as formatted JSON.
3. Time claims such as exp, iat and nbf are converted to readable dates, so you can see at a glance whether the token has expired.

Anatomy of a JWT

A JSON Web Token, specified in RFC 7519, is a compact way to transmit claims between parties. The common signed form (JWS) has three parts separated by dots:

header.payload.signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMifQ.<signature>

• Header: JSON describing the token, chiefly the signing algorithm. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 decodes to {"alg":"HS256","typ":"JWT"}.
• Payload: JSON containing the claims, the statements about the user or session.
• Signature: computed over the encoded header and payload with a secret (HMAC, e.g. HS256) or a private key (e.g. RS256, ES256).

Each part is encoded with base64url, the URL-safe Base64 alphabet without padding. That is why tokens contain - and _ and why JWTs almost always start with eyJ: that is how the opening {" of a JSON object encodes when a typical lowercase key name follows. You can explore the encoding itself with the Base64 encoder.

Registered claims

All of these are optional in RFC 7519; applications decide which they require. Time claims are in seconds, not milliseconds; the Unix timestamp converter explains the difference.

Common pitfalls

Decoding is not verifying

Anyone can decode a JWT; that is exactly what this tool does. Decoding tells you what a token claims, not whether those claims are genuine. A server must verify the signature with the correct key and check exp, nbf, iss and aud before trusting anything in the payload.

The payload is not secret

A signed JWT is readable by anyone who holds it. Do not put passwords, personal data you would not expose to the client, or internal secrets in the payload. If the contents must be confidential, use an encrypted JWT (JWE) or keep the data server-side.

alg: none and algorithm confusion

The JOSE specifications define an "alg": "none" value for unsecured tokens with an empty signature. A library that honours the token's own header might accept a forged token like this:

{"alg": "none", "typ": "JWT"}
{"sub": "admin"}
(empty signature)

A related attack switches an RS256 token to HS256 so that the public key is misused as an HMAC secret. The defence for both is the same: configure the allowed algorithms on the server and never let the token choose.

Tips

• Keep access tokens short-lived and use refresh tokens for longer sessions.
• Allow a small clock skew (for example, a minute) when checking exp and nbf across servers.
• Use a well-maintained JWT library rather than parsing and verifying tokens by hand.

Frequently asked questions

Can this tool verify a JWT signature?

Verification requires the issuer's secret or public key and must happen in your backend. This tool is for inspecting a token's header and claims while debugging.

Why does my token show as expired?

The exp claim is earlier than the current time on your device. Check that your clock is correct and that the issuer wrote exp in seconds.

Are JWTs encrypted?

Signed JWTs (JWS), the vast majority in use, are only encoded and signed, so anyone can read them. Encrypted JWTs (JWE) have five parts instead of three.

Is it safe to paste my token here?

The decoding happens locally and nothing is transmitted. As a general rule, avoid pasting live production tokens into any online tool you have not reviewed.