JWT decoder

A JSON Web Token (RFC 7519) has three parts separated by dots:

xxxxx.yyyyy.zzzzz
header.payload.signature

• The header says which algorithm signed the token, e.g. {"alg": "HS256", "typ": "JWT"}.
• The payload holds the claims: who the token is about and what it allows.
• The signature proves the first two parts were not changed by someone without the key.

The header and payload are just Base64URL-encoded JSON. They are not encrypted, so anyone holding the token can read them. That is exactly what this decoder does. Never put secrets or sensitive personal data in a JWT payload.

The decoder converts exp, nbf and iat to readable dates (shown in UTC) with a relative time, such as "in 14 minutes" or "3 days ago", and shows a status line: expired, still valid according to exp, not yet valid, or no expiration set.

Open Verify signature, enter the secret key, and click Verify. For tokens signed with HS256, HS384 or HS512 (HMAC with SHA-2), the tool recomputes the signature with the Web Crypto API and tells you whether it matches. Tick Secret is Base64URL-encoded if your key is stored that way, as some identity providers do.

Tokens signed with public-key algorithms such as RS256 or ES256 are not verified here; they need the issuer's public key, usually published at a JWKS endpoint.

Important: a decoded payload is not trustworthy until the signature is verified. A server must always verify the signature, and check exp, aud and iss, before trusting any claim.

• Treat tokens like passwords. A valid access token often lets anyone who has it act as you until it expires. Do not paste production tokens into websites unless you have to. This tool runs entirely in your browser and sends nothing, but the safest habit is to test with expired or development tokens.
• "alg": "none" means the token is unsigned. A server must never accept such a token; some old libraries did, which caused serious vulnerabilities.
• Algorithm confusion: servers should only accept the algorithm they expect, not whatever the token header says.
• Encrypted tokens (JWE) have five parts instead of three. Their content cannot be read without the key; the decoder recognizes them and tells you so.

• 401 Unauthorized right after login? Compare exp and iat with the current time. A server clock that is a few minutes off can make fresh tokens look expired or not yet valid.
• Wrong audience: the aud claim must match what your API expects, a common issue when one identity provider serves several apps.
• Missing permissions: check scope or role claims in the payload, such as scope, roles or permissions; their names depend on the provider.
• Signature mismatch: make sure you are using the right secret for the environment, and check whether it is Base64-encoded.

To decode the timestamps yourself, use the Unix timestamp converter; to look at raw Base64URL parts, use the Base64 decoder.