How to use the JWT decoder

  1. Paste a JSON Web Token into the box. A leading Bearer is removed automatically, so you can paste an Authorization header value as it is.
  2. The header and payload are decoded and formatted.
  3. Status labels show the signing algorithm, whether the token has expired, and whether it is not yet valid.
  4. Time claims such as iat, nbf, and exp are converted from Unix timestamps to readable dates.

Click Load example to see how a decoded token looks.

What is inside a JWT

A JWT has three parts separated by dots: header.payload.signature. Each part is Base64URL-encoded.

  • Header: the token type and the signing algorithm, for example {"alg":"HS256","typ":"JWT"}.
  • Payload: the claims, meaning statements about the user and the token, such as the user ID and expiry time.
  • Signature: created by the issuer from the header and payload with a secret or private key.

Common registered claims:

  • iss (issuer): who created the token.
  • sub (subject): usually the user ID.
  • aud (audience): which service the token is meant for.
  • exp (expiration time): after this moment, the token must be rejected.
  • nbf (not before): before this moment, the token must be rejected.
  • iat (issued at): when the token was created.
  • jti (JWT ID): a unique ID, often used to revoke a token.

Decoding is not verifying

Anyone can read a JWT's payload, because Base64URL is an encoding, not encryption. Anyone can also create a token with any payload. What makes a token trustworthy is the signature, and only a server with the correct key can verify it.

This tool decodes tokens so you can debug them. It does not verify signatures, and a "Not expired" label does not mean the token is genuine. Your application must always verify the signature, check exp, nbf, iss, and aud, and only accept the algorithms it expects.

Security tips

  • Do not put secrets in the payload. Passwords, card numbers, and personal data in a JWT are readable by anyone who sees the token.
  • Reject alg: none. Unsigned tokens should never be accepted by a production system. The tool flags them.
  • Keep tokens short-lived. Use an exp of minutes or hours and refresh tokens for longer sessions, because a stolen JWT is usually valid until it expires.
  • Treat tokens like passwords. A valid token gives access to an account. Prefer a token from a test environment when debugging, and do not paste production tokens into tools you do not trust.

Frequently asked questions

Is my token sent to a server?

No. Decoding runs entirely in your browser, and the token is not stored or logged.

Why can't the tool read my token?

If the token has five parts instead of three, it is an encrypted JWE, and the payload cannot be read without the decryption key. If decoding fails on a three-part token, it may have been cut off or had extra characters added when copying.