JWT Decoder

Decoding happens as you paste, with no button to press.

1. Paste the token into the box labelled Paste a JSON Web Token. A leading Bearer prefix copied from an Authorization header is removed for you.
2. Read the Decoded token output. It lists HEADER (algorithm and type), then PAYLOAD (the claims), both as indented JSON.
3. Look at the TIMES block, which appears when the payload has iat, nbf or exp. Each is written as a UTC date with a relative note such as 3 days ago or in 2 hours.
4. Read the line under the output. It says Token valid for another a length of time, Token EXPIRED with how long ago, or No expiry claim, followed by the algorithm.
5. Check SIGNATURE at the end, which shows the algorithm and the length of the raw third segment, marked as not verified.

If the text is not a token you get a message: fewer than two dot-separated parts, or Could not decode with the reason. Expiry is judged against your own device clock, so a wrong clock gives a wrong status.

When a real token will not decode, look for the usual causes: quote marks or a line break picked up while copying, a segment cut off by an email client, only the payload pasted, or an opaque access token that is a random string rather than a JWT at all. Those have no dots to split on, and nothing can be read from them without the issuer.

A JSON Web Token is three Base64URL strings joined by dots: header.payload.signature. Base64URL swaps + and / for - and _ and drops the = padding so the token travels safely in URLs and headers. The header segment eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 decodes to {"alg":"HS256","typ":"JWT"}. A payload segment that begins eyJzdWIiOiIxMjM0NTY3ODkwIiwi can decode to this:

The registered claim names come from RFC 7519: iss issuer, sub subject, aud audience, exp expiry, nbf not before, iat issued at and jti a unique token ID. Dates are Unix seconds, and the payload JSON keeps them as numbers; only the TIMES block translates them. To convert any other value by hand, use the Unix timestamp converter, and for a single segment the Base64 encoder and decoder.

Anyone holding a token can read it, because the header and payload are encoded rather than encrypted. This page shows exactly what any client or proxy could see, and no more.

• The signature is not checked. That needs the HMAC secret or the issuer public key, which should never be pasted into a web page. Treat the output as a view of the claims, not proof they are genuine.
• Only the exp claim sets the valid or expired message. A future nbf is displayed but does not change the status.
• Only the compact three-part form is read. An encrypted token (JWE) has five parts and will not decode.
• Never put passwords or card numbers in a payload. Keep such data on the server.

On the server side, verify the signature, allow only the algorithms you expect and reject alg set to none, a flaw that let early libraries accept unsigned tokens. Then validate exp, nbf, iss and aud, since a correctly signed token meant for another service is still the wrong token. A readable dump also helps when checking that a payload is valid JSON, for which the JSON formatter is useful.

Lifetimes matter as well. Short-lived access tokens limit the damage if one leaks. A decoded token cannot be revoked by looking at it, so services that need instant logout keep a deny list or rely on short expiry times with a separate refresh path.