HandyBench

JWT Decoder

Decode JWT header and payload claims.

How to use the JWT Decoder

  1. 1 Paste your JWT (the three dot-separated parts).
  2. 2 Read the decoded header and payload.
  3. 3 Check expiry (exp) and issued-at (iat) as readable dates.

What is inside a JWT

A JSON Web Token (RFC 7519) is three base64url strings joined by dots: header.payload.signature. Base64url, defined in RFC 4648 section 5, is ordinary Base64 with - and _ in place of + and /, and with the trailing = padding removed. This decoder restores the padding, decodes each of the first two parts as UTF-8 text, parses them as JSON and pretty-prints them. Nothing is calculated with a key, because decoding needs none.

Worked example

The header segment eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 decodes to {"alg":"HS256","typ":"JWT"}. A payload containing "iat":1516239022 and "exp":1516242622 is reported as:

exp: Thu, 18 Jan 2018 02:30:22 GMT (expired)
iat: Thu, 18 Jan 2018 01:30:22 GMT

The two numbers are Unix seconds, exactly one hour apart, so the token lived for 3,600 seconds.

ClaimMeaningShown by this tool
expExpiry timeUTC date plus "expired" or "valid"
iatIssued atUTC date
nbfNot valid beforeUTC date
sub, iss, audSubject, issuer, audienceVisible in the payload JSON only

What "valid" does and does not mean

The "(valid)" label only compares exp with your computer's clock. It says nothing about the signature, the issuer or the audience. Anyone can write a payload and put any expiry in it, and only your server, holding the key, can tell a genuine token from a forged one. Never make an authorisation decision from decoded contents. Also note that the payload is encoded, not encrypted, so keep secrets such as passwords out of it.

Why a token may fail to decode

  • A leading Bearer prefix copied from an Authorization header is stripped for you, and spaces or line breaks inside the token are ignored.
  • Only the first two segments are read, so a truncated token with a missing signature still decodes.
  • Encrypted tokens (JWE) have five segments and cannot be read without the key, so the tool tells you that instead of showing claims. Any other number of dot-separated parts is reported with the count it found, and a part that is not valid base64url or JSON is named in the error.
  • Claims are only interpreted as dates when they are JSON numbers. A string such as "1516242622" is shown but not converted.

To see how a token is assembled, build one with the JWT encoder. To inspect an individual segment by hand, use Base64 decode.

Examples

  • ▸ Reading the exp claim of an access token to see why an API call returned 401.
  • ▸ Decoding the header to check which signing algorithm (alg) a token claims to use.

Frequently asked questions

Does this verify the token signature?

No. It decodes the header and payload only. Decoding never requires the secret, and your token is processed locally and never sent anywhere.

Is it safe to paste a real token here?

Decoding happens entirely in your browser. Still, treat live tokens carefully and avoid pasting production secrets into any web tool.

What does "(valid)" next to exp mean?

It only means the exp time is later than your computer clock. It does not mean the signature is genuine or that the issuer and audience are correct. Only the server that holds the key can verify those.

Is the JWT payload encrypted?

No. A standard signed JWT is only base64url-encoded, so anyone holding the token can read the payload, as this tool shows. Never put passwords or other secrets in the claims.

Can I paste a token straight from an Authorization header?

Yes. A leading "Bearer " prefix and any line breaks or spaces inside the token are ignored. Encrypted tokens (JWE) with five segments cannot be read, since their contents are encrypted, and the tool says so instead of showing claims.

What are exp, iat and nbf?

They are standard claims holding Unix times in seconds: exp is when the token expires, iat is when it was issued, and nbf is the earliest time it is valid. This tool shows each one as a UTC date.