JWT Decoder

About the JWT Decoder

Paste a JWT to see its decoded header and payload as formatted JSON, plus the standard claims (exp, iat, sub) translated into readable timestamps. This is a decoder, not a verifier — it does not check the signature.

How to use the JWT Decoder

1. Paste a JWT (three dot-separated Base64url segments).
2. The header and payload are decoded and pretty-printed automatically.
3. Expiry and issued-at claims are shown as human-readable dates.
4. Copy either segment individually.

Step-by-step walkthrough with examples and the errors people hit: How to Decode a JWT and Check Expiry.

Example

Example token

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSJ9.sig

{ "alg": "HS256" }
{ "sub": "1234567890", "name": "Ada" }

Common errors and how to fix them

More problems and fixes in the tutorial

The anatomy of a JSON Web Token

A JWT is three Base64url-encoded segments separated by dots. The header names the signing algorithm and token type; the payload carries the claims; the signature is a MAC or digital signature over the first two parts. Because the first two parts are only encoded, not encrypted, anyone holding a token can read them, and this decoder shows both pretty-printed, with the timestamps translated into dates.

The standard claims, decoded

iss is the issuer, aud the intended audience, sub the subject (usually the user id). exp is the expiry, nbf the not-before time and iat the time of issue, all as Unix timestamps in seconds. jti is a unique token id used for revocation lists. Everything else is application-specific: roles, scopes, tenant ids, email. When a request is rejected with 401, comparing these values with what the server expects is the fastest diagnosis.

Why a token is rejected: expiry and clock skew

Most JWT failures are time. The decoder marks the token Expired when exp is in the past and shows the remaining lifetime otherwise. Tokens are also refused when nbf is in the future, and when the client's and server's clocks disagree by more than the server's tolerance (often 30 to 60 seconds). If a freshly issued token is rejected, check the machine clock before the code.

Decoding is not verifying

Reading a token proves nothing about who created it. Verification recomputes the signature with the secret (HS256) or checks it with the issuer's public key (RS256, ES256), and only the server should do that. This page intentionally does not accept secrets or keys: paste a token, read it, and leave verification to your backend or identity provider.

Security notes

Decoding happens in your browser; the token is never sent anywhere. Even so, production tokens are credentials. Decode them on a page you trust, avoid pasting them into chat, and prefer short-lived tokens with refresh flows so a leaked one is worthless quickly. Be suspicious of alg: none and of tokens whose header algorithm differs from what your server expects.

FAQ