JWT decoder

Decode any JSON Web Token: see its header, payload and every claim in plain words, check when it expires and verify its signature.

Decodes as you type.

  • HeaderAlgorithm and token type
  • PayloadThe claims: who, for whom, until when
  • SignatureProof the token was not changed

Related tools

See all tools

How to use the JWT decoder

Use it whenever you need to decode a JWT online: to read an ID token after a login, to see which scopes an access token carries, or to find out why an API rejects a token. It is a JWT parser and a JWT viewer in one, and it works with a JWT token from any library or identity provider.

  1. Paste your token into the box. It decodes as you type, so there is no button to press. A Bearer prefix, quotes, line breaks, or a whole callback URL or JSON response are fine: the decoder finds the token inside and tells you what it cleaned up.
  2. Read the three parts. The header, the payload and the signature each get their own colour, in the box and in the cards below it. Explained shows every field with its meaning, JSON shows the raw objects ready to copy.
  3. Look at the summary card. It says whether the token has expired, when it was issued, who issued it and who it is for.
  4. To check that the token is genuine, open Verify signature and add the secret or the public key.

What a JSON Web Token is made of

A JWT is three pieces of text joined by dots: header.payload.signature. The header and the payload are JSON objects written in Base64URL, which is an encoding, not encryption. That is why a JWT decoder can read any token without a key, and why anyone who gets hold of your token can read it too. The signature is the only protected part. It proves the header and payload have not been changed since the issuer signed them.

Encrypted tokens (JWE) have five parts instead of three. The decoder reads their header, shows the size of each part and tells you the claims are encrypted.

Claims the decoder explains

  • Registered claims: iss (issuer), sub (subject), aud (audience), exp (expires), nbf (not before), iat (issued at) and jti (token ID).
  • OpenID Connect claims from ID tokens: email, name, nonce, auth_time, azp, at_hash, amr, acr and the rest of the standard profile.
  • Claims from the big identity providers: Microsoft Entra (tid, oid, upn, scp), Amazon Cognito (token_use, cognito:groups), Keycloak (realm_access, resource_access), Auth0 (permissions) and Google (hd).

Times are shown as dates in your own time zone, with how long ago or how far ahead they are, so the decoder doubles as a JWT expiration checker. The expiry countdown updates every second. Anything the decoder does not know is labelled as a custom claim.

Decoding is not verifying

Anyone can build a token with any payload, so reading it proves nothing on its own. To verify the JWT signature, add the key under Verify signature:

  • HS256, HS384, HS512: the shared secret, as plain text or Base64URL.
  • RS256 to RS512, PS256 to PS512, ES256 to ES512, EdDSA: a PEM public key, an X.509 certificate, a JWK, or a whole JWKS, where the key is picked by kid.

The check runs on your device with the browser's own WebCrypto. A token can have a valid signature and still be expired: the result tells you both. The tool never fetches a jku or x5u URL and never trusts a key carried inside the token itself. If you paste a private key by mistake, it refuses to use it.

Mistakes it points out

  • alg set to none, which means the token is not signed at all.
  • No exp claim, or a lifetime of more than a year.
  • exp or iat written in milliseconds instead of seconds, a common bug that makes tokens look valid for thousands of years.
  • An ECDSA signature of the wrong length, usually DER encoded instead of the raw format JWS needs.
  • Standard Base64 characters (+, /, =) where Base64URL is required.
  • Fields such as password or secret in the payload, which anyone holding the token can read.
  • Headers that point at their own key (jku, x5u, jwk), short HMAC secrets and RSA keys under 2048 bits.

Is it safe to paste a token here?

The token is decoded in your browser and is not uploaded or stored, and nothing about it goes into the page address. You can read more on how PieToolkit tools work and in our privacy policy. Even so, treat a live access token like a password: anyone holding it can use it until it expires. When you can, use a test token or one that has already expired.

Frequently asked

Can I decode a JWT without the secret?

Yes. Decoding only reverses Base64URL, so no key is needed. The secret or public key is only needed to verify the signature.

Can it decrypt an encrypted JWE?

No. Reading the claims of a JWE needs the recipient's private key, and you should never paste one into a website. The decoder shows the header and the algorithms instead.

Why does my token show as expired when the server accepts it?

The decoder compares exp with your device's clock. Your clock may be off, or the server may allow a few minutes of clock skew.

Looking for more? See all developer tools.

Your files stay on your device

Every tool runs inside your browser. The files you add are never uploaded, never stored and never seen by anyone at PieToolkit.

How we handle your data