JWT Decoder

Paste a JSON Web Token to read its header and payload, see when it was issued and when it expires, spot risky settings and check the signature with your secret or public key. Nothing leaves your browser.

Try an example:

Private by design: the token is decoded on your device and the signature is checked with your browser’s Web Crypto. Tokens and keys are never uploaded, stored or logged. Even so, treat live tokens like passwords.

How to use the JWT Decoder

  1. Copy a token. It usually comes from an Authorization: Bearer … header, a cookie, local storage, or your identity provider’s debug screen. You can paste the whole header line; “Bearer” is removed for you.
  2. Paste it into the box and press Decode token. The token is split into its three coloured parts, and the header and payload are shown as formatted JSON.
  3. Read the verdict at the top. It tells you if the token is valid now, expired, not yet valid or unsigned, plus the signing algorithm and key ID.
  4. Check the Claims table. Times such as exp, iat and nbf are converted to UK time and UTC, with “in 20 minutes” or “3 days ago” beside them.
  5. Look at Things to check for warnings about risky settings.
  6. To prove the token is genuine, paste the secret (for HS256, HS384, HS512) or the public key (for RS, PS, ES and EdDSA) and press Verify signature.

If you enjoy what we do, consider supporting us. Every little bit means the world! Support Catpool on Ko-fi

What is a JWT?

A JSON Web Token (JWT, pronounced “jot”) is a compact way to pass signed information between systems, defined in RFC 7519. It’s widely used for sign-in sessions, API access tokens and OpenID Connect ID tokens. A token has three parts separated by dots:

  • Header (red): which algorithm signed the token, and often a key ID (kid).
  • Payload (purple): the claims, such as who the user is, who issued the token and when it expires.
  • Signature (green): proof that the header and payload haven’t been changed since the issuer signed them.

The header and payload are only base64url encoded, not encrypted. Anyone who has a token can read what’s inside, which is exactly what this tool does. What they can’t do, without the key, is change it and still pass the signature check.

Understanding the claims

  • iss (issuer): who created the token, such as your login service.
  • sub (subject): who the token is about, usually a user ID.
  • aud (audience): which application the token is meant for. An API should reject tokens meant for something else.
  • exp (expiry), nbf (not before) and iat (issued at): times in seconds since 1 January 1970. The tool spots the common mistake of using milliseconds, which makes a token last thousands of years.
  • jti (token ID): a unique ID that lets a server block a token from being reused.

Security warnings explained

The decoder flags settings that are often behind real-world JWT vulnerabilities:

  • alg “none”: an unsigned token. If a server accepts these, anyone can sign in as anyone.
  • No expiry: a leaked token keeps working until the signing key is changed.
  • Very long lifetimes: access tokens are usually valid for minutes or hours, not months.
  • jku, x5u or jwk in the header: the token is telling the server where to find its own key. A server must only use keys it already trusts.
  • Sensitive-looking fields such as “password” or “card” in the payload, which anyone holding the token can read.
  • Short HMAC secrets: HS256 needs at least 32 random bytes. Short or guessable secrets can be cracked offline from a single token.

Checking the signature

Decoding shows what a token says. Verifying shows it’s genuine. For HMAC tokens (HS256, HS384, HS512), paste the shared secret, and tick “base64 encoded” if your secret is stored that way. For RSA, RSA-PSS, ECDSA and Ed25519 tokens, paste the public key as PEM (“BEGIN PUBLIC KEY”) or as a JWK, including a JWKS with a keys array. You can usually find the public keys at your provider’s /.well-known/jwks.json address. Never paste a private key: verification only ever needs the public half, and the tool refuses private keys.

Privacy

Many online JWT tools send your token to a server. This one doesn’t. Decoding and signature checks happen entirely in your browser using the built-in Web Crypto API. Tokens, secrets and keys aren’t uploaded, stored or logged, and the secret box is cleared when you leave the page. Even so, a live token is like a password. If you’ve shared one anywhere you shouldn’t have, sign out or revoke it so it stops working.

Frequently asked questions

Can this decode an encrypted token (JWE)?

No. Encrypted tokens have five parts and can only be opened with the recipient’s private key. The tool tells you when it sees one.

Why does it say “expired” when my app accepts the token?

Some servers allow a few minutes of clock skew, and your device’s clock may differ slightly. Check the exact time in the Claims table.

My signature check fails but the token works. Why?

Usually it’s the wrong key (check the kid matches), a secret that is base64 encoded, or extra spaces or line breaks copied with the key.

Does verifying here make the token safe to trust?

It proves the token was signed with that key. Your server must also check exp, aud, iss and the expected algorithm on every request.

Related: Catpool home, Developer, Base64 Encode/Decode, JSON Formatter, Unix Timestamp Converter, Text Encrypt and Decrypt.

Related tools