JWT Decoder

What Is a JSON Web Token?

A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties. It is commonly used for authentication and authorization: a server issues a token after login, the client sends it with later requests, and the server verifies it before granting access. A JWT is not encrypted by default; it is encoded and signed, which means anyone who has the token can read its header and payload.

This JWT Decoder shows the token's header and payload as readable JSON, along with time claims such as exp, iat and nbf. The decoding happens locally in your browser.

JWT Structure

A signed JWT (JWS) has three parts separated by dots:

header.payload.signature

• Header: JSON describing the algorithm and token type, for example {"alg":"HS256","typ":"JWT"}.
• Payload: JSON containing claims about the subject, issuer, audience and timestamps.
• Signature: a cryptographic value used to verify that the token was issued by a trusted party and was not modified.

The header and payload are Base64URL-encoded, not encrypted. The signature is computed over the encoded header and payload using a secret or private key, depending on the algorithm.

How to Decode a JWT

1. Paste the full token, including all three dot-separated parts, into the input box.
2. Select Decode JWT.
3. Read the header and payload in the result panel.
4. Check the expiry status and the time claims such as exp, iat and nbf.

If the token is malformed, the decoder reports an error. Common causes are missing parts, invalid Base64URL characters, missing padding or a payload that is not valid JSON.

Common JWT Claims

• iss — issuer of the token.
• sub — subject, usually the user or entity the token describes.
• aud — intended audience.
• exp — expiration time as a Unix timestamp.
• nbf — “not before” time, the earliest moment the token is valid.
• iat — issued-at time.
• jti — unique token identifier, useful for revocation lists.

What Decoding Does Not Do

Decoding is not verification. This tool does not check the signature, issuer, audience or permissions. A token can be decoded by anyone who has it, so decoded data must not be trusted until the server verifies the signature with the correct key and validates the claims. Never rely on client-side decoding for access control.

Do not put passwords, private keys or sensitive personal data in a JWT payload. The payload is readable by anyone who obtains the token, and tokens often end up in browser storage, logs or URLs.

JWS vs JWE

A JWS is signed and readable. A JWE is encrypted and has five parts. This decoder can show the JWE header, but it cannot read the encrypted payload without the decryption key. If you paste a five-part token, the payload will be marked as encrypted rather than decoded.

Common Decoding Errors

Missing or extra dots

A signed JWT must have exactly three parts. A five-part token is a JWE, not a JWS. Copy the token exactly as issued; do not insert spaces or line breaks.

Invalid Base64URL

JWT segments use Base64URL, which replaces + with - and / with _. Standard Base64 characters, truncated strings or missing padding can cause errors.

Expired tokens

An expired token can still be decoded; the payload is readable. Expiry only affects whether the token should be accepted by a server. This decoder labels the token as valid or expired based on exp, but it does not verify the signature.

Security Best Practices

• Verify tokens on the server, never only in the browser.
• Validate the algorithm, issuer, audience and expiry.
• Use short-lived access tokens and refresh tokens where appropriate.
• Keep signing keys secret and rotate them when needed.
• Do not store sensitive data in the payload.

Related Tools

Decode token segments with the Base64 Encoder / Decoder, format the JSON payload with the JSON Formatter, or convert exp and iat values with the Unix Timestamp Converter.