JWT Decoder

How the JWT Decoder works

A signed JWT (JWS) has three parts separated by dots: header.payload.signature. The header and payload are JSON objects encoded with URL-safe Base64 without padding. The decoder removes a Bearer prefix and any line breaks, splits the token, decodes each part as Base64URL and UTF-8, and parses the JSON. Each step reports its own error, for example which part contains an invalid character or where its JSON is broken. Encrypted tokens (JWE, five parts) cannot be read without the key and are reported as such.

The header and payload are shown pretty-printed, with number values kept exactly as written. The registered claims from RFC 7519 (iss, sub, aud, exp, nbf, iat and jti) are listed with their meaning. The time claims are seconds since 1970-01-01 UTC; they are shown as UTC and local dates with how long ago or how soon they occur, such as "Expired 3 hours ago".

The signature is not verified. Checking it needs the secret or public key and must happen on your server; anyone can build a token with any payload. The tool warns when the header says "alg": "none", which means the token is not signed at all.

How to use the JWT Decoder

1. Paste the token into the JSON Web Token box, or select Load example. A leading "Bearer " is removed automatically.
2. Select Decode JWT, or press Ctrl + Enter (Cmd + Enter on a Mac).
3. Read the summary for the algorithm, type, time validity and signature size, and check any warnings.
4. Review the formatted header and payload, and use Copy to copy either one as JSON.
5. Check the Registered claims table to see who issued the token, who it is for, and when it was issued and expires.

Example

The example token from jwt.io:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

decodes to this header:

{
  "alg": "HS256",
  "typ": "JWT"
}

and this payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

The claims table explains sub (Subject) and shows iat (Issued at) as 2018-01-18 01:30:22 UTC, the same moment in your time zone, and how long ago that was. The token has no exp claim, so the summary shows "No expiry (exp) claim".

Common use cases

• Checking which claims, roles or scopes an identity provider puts into an access token or ID token.
• Finding out why an API returns 401 Unauthorized, for example an expired token or the wrong audience.
• Converting exp, nbf and iat timestamps into readable dates while debugging clock skew.
• Confirming the signing algorithm in the header before configuring token validation.
• Inspecting test tokens generated by your own authentication code.

Common errors and how to fix them

A JWT has three parts separated by dots, but this input has a different number

The token was truncated when copied, or it is not a JWT. Copy the whole value and strip any Bearer prefix from the Authorization header.

The algorithm is none

The token is unsigned, so anyone can create or alter it. This is a security finding rather than a decoding problem: never accept alg none tokens in production.

An expiry date is shown hundreds of years in the future

The token carries milliseconds where JWT requires seconds since 1970. That is a bug in whatever issued the token, so the tool flags it rather than quietly reinterpreting the value.

The token decodes here but the API rejects it

Decoding is not verification. This tool reads the header and payload, which anyone can do, but it does not check the signature. Rejection usually means an invalid signature, a wrong issuer or audience, or an expired token.

Frequently asked questions