Does this JWT decoder verify the signature?

No. It only decodes the header and payload, which are base64url-encoded JSON that anyone can read. Checking the signature needs the secret or public key, and that check belongs on the server that accepts the token.

Is it safe to paste a real token here?

The decoder runs entirely in your browser and never sends the token anywhere. Even so, treat a live access token like a password: anyone who has it can use it until it expires.

A normal signed JWT (JWS) is not encrypted: the payload is only encoded, so anyone can decode it. Encrypted tokens (JWE) have five parts instead of three, and this tool does not decode them.

What do iat, nbf and exp mean?

iat is when the token was issued, nbf is the time before which it must not be accepted, and exp is the time on or after which it must not be accepted. All three are seconds since January 1, 1970 UTC.

Why does my token show as expired when it still works?

Servers may allow a small leeway for clock differences, which RFC 7519 says is usually no more than a few minutes. Also check your computer's clock, because the status is calculated from it.

JWT Decoder: Read the Header, Payload and Expiry Locally

A JSON Web Token (JWT) carries claims such as a user ID, roles and an expiry time between a login server and an API. When an API rejects a request, it helps to see what the token actually says and whether it has expired. This decoder shows the header and payload as formatted JSON and turns the time claims into readable dates. It runs entirely in your browser: the token is never sent anywhere.

Important: This tool decodes a token; it does not verify its signature. A decoded token proves nothing about who issued it.

How to use the JWT decoder

Paste the token, the three parts separated by dots: header.payload.signature.
Read the decoded header and payload as formatted JSON.
Check the algorithm (alg) and type (typ) taken from the header.
Look at the time claims: iat (issued at), nbf (not before) and exp (expires), each shown in your local time and in UTC.
Read the status: expired, not yet valid, or within its validity window.

How it works

A signed JWT uses the JWS Compact Serialization from RFC 7515: three base64url strings joined by dots.

BASE64URL(header) . BASE64URL(payload) . BASE64URL(signature)

Base64url is the URL- and filename-safe variant of base64 from RFC 4648, section 5: it uses - and _ instead of + and /, and JWTs leave off the trailing = padding. The decoder reverses that encoding for the first two parts and parses the result as JSON. It doesn’t need any key to do so, which is the point to remember: the header and payload of a signed JWT are readable by anyone who has the token.

The time claims are NumericDate values: the number of seconds since 1970-01-01T00:00:00Z UTC (RFC 7519, section 2). The status compares them with your computer’s clock:

Expired: the current time is on or after exp. RFC 7519 says the token must not be accepted for processing from that moment.
Not yet valid: the current time is before nbf.
Within its validity window: neither of the above applies.

Why decoding is not verification

The third part of the token is a signature over the encoded header and payload. It protects their integrity, but only for someone who checks it with the right key: a shared secret for HMAC algorithms such as HS256, or the issuer’s public key for RS256 or ES256. Without that check, anyone can write a token with any claims they like, for example "role": "admin", encode it and paste it here, and it will decode just as cleanly as a genuine one. RFC 7519 even defines unsecured tokens with "alg": "none" and an empty signature.

So use this decoder to read and debug tokens. The decision to trust a token belongs on the server, which verifies the signature with its key, checks the algorithm against the ones it accepts, and validates exp, nbf and the other claims as RFC 7519, section 7.2, describes. RFC 7519 also warns that a token’s contents can’t be relied on for a trust decision unless they are cryptographically secured.

Encrypted tokens (JWE)

An encrypted JWT uses the JWE Compact Serialization from RFC 7516, which has five base64url parts separated by four dots: protected header, encrypted key, initialization vector, ciphertext and authentication tag. Its payload can only be read with the decryption key, so this tool doesn’t decode JWE tokens.

Worked example

This sample token was signed with an example key:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzY3MjI1NjAwLCJleHAiOjE3NjcyMjkyMDB9.BHufPa6GN2Kd2LGQ1_cgpxC0qZMN6AcL1c6ZIaTkooY

The first part decodes to the header:

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

The second part decodes to the payload:

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "iat": 1767225600,
  "exp": 1767229200
}

Claim	Value	Date (UTC)
`iat`	1767225600	January 1, 2026, 00:00:00
`exp`	1767229200	January 1, 2026, 01:00:00

The token was valid for one hour (3,600 seconds), so the decoder reports it as expired. Notice that nothing in the decoding used the signing key: the third part is just carried along.

Common JWT claims

Claim	Name	What it holds
`iss`	Issuer	Who issued the token
`sub`	Subject	Who the token is about, usually a user ID
`aud`	Audience	Who the token is meant for
`exp`	Expiration time	When it stops being acceptable
`nbf`	Not before	When it starts being acceptable
`iat`	Issued at	When it was issued
`jti`	JWT ID	A unique ID for the token

The decoded header and payload are plain JSON: tidy or minify other JSON in the JSON formatter.
More developer guides and error fixes are in Programming.
See all our free developer tools, including the chmod calculator and number base converters.

JWT Decoder