Decode a JWT Online: Header, Payload and Expiry

To decode a JWT online, paste the token into the box and read the result. The tool splits it into its three parts, decodes the Base64URL header and payload, shows both as formatted JSON, reports the signing algorithm, and translates the time claims into readable UTC dates. The token is decoded in your browser, not uploaded.

There is one limitation to state before anything else: this tool decodes, it does not verify. It can show you that a signature segment exists, but it cannot tell you whether that signature is valid without the secret or public key. Decoding a JWT proves what it claims, not that the claims are trustworthy.

#What a JWT contains

A JSON Web Token is three Base64URL segments joined by dots:

header.payload.signature

• Header is a JSON object naming the token type and signing algorithm, such as {"alg":"HS256","typ":"JWT"}.
• Payload is a JSON object of claims: who the token is about, who issued it, when it expires, and any application-specific data.
• Signature is a cryptographic value over the first two segments. It is not JSON and is not decoded into a readable object.

Because the first two segments are only Base64URL encoded, anyone holding the token can read them. That is by design: a JWT is signed, not encrypted. If you need to hide the payload, you need encryption (JWE), not a signed JWT.

#How to decode a JWT

1. Open the JWT decoder.
2. Paste the full token, including all three segments and the dots between them.
3. Press Decode.
4. Read the summary: signature status, algorithm, expiry status and a short claim list.
5. Expand the header and payload JSON for the complete contents.

The summary is the quick answer; the JSON is the source of truth. Both come from the same decode.

#Reading the result

Time claims are shown twice: as the raw Unix timestamp and as a UTC date. That avoids the usual mistake of comparing a local time against a UTC value and concluding a token expired when it has not.

#The registered claims worth knowing

• iss (issuer): who created the token. Your app should check it matches the expected identity provider.
• sub (subject): who the token is about, usually a user ID.
• aud (audience): who the token is for. A token issued for one service should not be accepted by another.
• exp (expiration): the time after which the token must be rejected.
• nbf (not before): the time before which the token must be rejected.
• iat (issued at): when the token was created. Useful for age checks, not a security control by itself.
• jti (JWT ID): a unique identifier, used for replay detection or revocation lists.

The decoder summarises these, but it does not enforce them. Expiry status is informational: a backend must still reject an expired token.

#Common problems and fixes

"A JWT must have three parts." The token is truncated, has a stray space, or is a JWE with five segments. Copy the complete value without a Bearer prefix.

"The header contains characters that are not valid Base64URL." The token was copied with line breaks inside a segment, or it is not a JWT. Base64URL uses - and _ instead of + and /, and the decoder rejects anything else.

"The payload is not valid JSON after decoding." The segment decoded to bytes that are not a JSON object. The token may be corrupted or may use a different structure.

The signature shows as present but I need verification. That is expected. Verification requires the signing secret (HMAC) or public key (RSA/ECDSA), and it is a backend responsibility. Never ship a secret in a browser tool.

The token looks expired but the API accepts it. Clock skew, a different time source, or a backend that does not check exp. The decoder uses your system clock in UTC.

The payload is unreadable. It is likely encrypted (JWE), which has five segments. A signed JWT's payload is always readable; that is the point.

The token works in one environment and fails in another. Check iss, aud and the key set used by each environment. A token minted for staging is usually rejected by production.

#Security rules that matter

• Decoding is not validation. Anyone can craft a token with any payload and a garbage signature. The tool will still display the claims.
• Never trust a token because it decodes. The backend must verify the signature, then check exp, nbf, iss and aud.
• Do not paste production tokens into random sites. This tool processes the token in your browser, but a token is still a bearer credential: anyone who obtains it can act as the user until it expires. Use test tokens when possible.
• Treat the payload as public. Do not put secrets, passwords or personal data in claims. They are readable by anyone with the token.
• Reject alg: none. A backend that accepts unsigned tokens has no authentication.
• Pin the algorithm. Do not let the token choose between HMAC and RSA in a way that allows a key-confusion attack.

#How this fits with Base64

A JWT segment is Base64URL, a variant of Base64 that replaces + and / with - and _ and omits padding. If you need to encode or decode arbitrary text, the Base64 encoder handles the standard alphabet with padding. The JWT decoder does the URL-safe variant internally and expects JSON objects in the first two segments.

If a decoded payload is hard to read, paste it into the JSON formatter for indentation and validation. The decoder already pretty-prints, but the formatter is useful when you are comparing two tokens side by side.

#Tips for debugging tokens

• Check the header first. The alg and kid values tell you which key should have signed the token.
• Compare iat and exp. A token with an exp in the past is the most common cause of a 401.
• Look at aud before blaming the signature. The right signature with the wrong audience is still a rejection.
• Decode both sides of a mismatch. If a client and server disagree, decode the exact token each one sees.
• Do not log full tokens. Log the jti or a hash instead. Logs are often less protected than the token store.
• Use short expiries. A leaked token is only useful until it expires; long-lived tokens raise the cost of a leak.

#Frequently asked questions

#Bottom line

Decoding a JWT is the fastest way to see what a token actually asserts: the algorithm, the subject, the audience and the expiry. Just keep the distinction between reading and trusting. Open the JWT decoder to inspect a token, then verify it properly on the server before acting on any claim.