JWT Decoder

How to decode a JWT

1. Paste the token into the box. If you copied the whole Authorization header value, the leading Bearer is stripped automatically. Example token fills in a sample so you can see the layout first.
2. The header and payload appear side by side as indented JSON, each with its own copy button.
3. The table underneath lists the signing algorithm and the standard claims it finds. Times are turned into readable dates in your time zone, with a note such as “expired 2 hours ago”, “valid, expires in 5 days” or “not valid yet”.

If something is wrong, the status line says what: the text has no dots, a part isn’t valid Base64url, a part isn’t valid JSON, or the token has no signature part.

Anatomy of a token

A JSON Web Token (RFC 7519) is three Base64url strings joined by dots: header.payload.signature. Base64url is ordinary Base64 with - and _ instead of + and / and without = padding, so the token can sit in a URL or HTTP header untouched. Here is a complete token signed with HS256 and the secret demo-secret:

Join the three with dots and paste the result above. The decoder reports it was issued at 00:00 UTC on 1 January 2026 and expired one hour later. Almost every JWT starts with eyJ, because that is what {" followed by a letter becomes in Base64 – a handy way to spot one in a log file.

Claims you will see

• iss (issuer) – who created the token, often the URL of an identity provider.
• sub (subject) – who it is about, usually a user ID.
• aud (audience) – which service should accept it. Can be a string or a list.
• exp, nbf, iat – expiry, not-before and issued-at times in seconds since 1970. The Unix Timestamp Converter shows them in any unit.
• jti – a unique token ID, used to block replays or revoke a single token.

Anything else, such as name, email, role or scope, is application-specific and appears only in the payload view. In the header, kid names the key used for signing, which helps a server pick the right public key from its key set.

Decoding is not verifying

This page reads a token; it does not check whether the token is genuine. The header and payload are merely encoded, so anyone can create a token claiming "role":"admin". Only the signature prevents that, and checking it requires the HMAC secret or the issuer’s public key, which belong on the server that accepts the token. A server should:

1. verify the signature with an algorithm it expects, never with whatever the header says – and reject "alg":"none", which means “unsigned”;
2. check exp and nbf against its own clock, allowing a small tolerance for clock drift;
3. confirm that iss and aud are the values it trusts.

Use a maintained JWT library for this rather than hand-written code; a decoder like this one is for debugging, not for deciding who gets in.

Signing algorithms

• HS256 / HS384 / HS512 – HMAC with a shared secret. Whoever can verify can also create tokens, so the secret must stay on trusted servers.
• RS256, PS256 – RSA signatures. The issuer signs with a private key; anyone can verify with the public key.
• ES256 – ECDSA on the P-256 curve; smaller keys and signatures than RSA.
• EdDSA – Ed25519 signatures, increasingly common in newer systems.

Debugging tips

• A token that “stopped working” is most often simply expired. Compare exp with the current time first.
• A token that is “not valid yet” right after login usually means the clocks of the issuing and receiving servers disagree.
• A 401 error with a fresh token often means the wrong audience: compare aud with the API you are calling.
• To look at the raw bytes of a single part, the Base64 decoder with URL-safe mode works too.

FAQ

Is it safe to paste a real token here?

Decoding happens entirely in this page’s JavaScript; the token is not uploaded. Even so, a live token is a credential that works until it expires, so prefer expired or test tokens, and never post real ones in tickets or chat.

Can I put sensitive data in the payload?

No. Anyone holding the token can read it, as this page shows. If the content itself must be confidential, use an encrypted token (JWE), which has five parts instead of three and cannot be decoded without the key.

Why does it say the token has no signature part?

The input has only two parts. That happens when a token was cut off while copying, or with unsigned tokens, which a server should refuse.

How do I make a token invalid before it expires?

A signed JWT can’t be changed once issued. Systems that need early logout keep tokens short-lived and maintain a server-side denylist of jti values or rotate the signing key.