JWT Decoder

How to decode a JWT

1. Paste the token into JSON Web Token. A full Authorization: Bearer … value also works: the Bearer prefix and any line breaks are removed.
2. The token is decoded as you type (or click Decode). The Header and Payload appear as formatted JSON, each with its own Copy button.
3. Read the Time claims table: exp, nbf and iat are shown with their raw value, the date in your time zone, a relative time (“in 3 hours”, “2 days ago”) and a status such as Expired or Not yet valid.
4. Check the warnings above the results, for example when alg is none or when a date looks like milliseconds.
5. To check the signature, fill in the key under Verify the signature and click Verify signature.

Decoding is not verifying

A JWT is three Base64url parts separated by dots: header.payload.signature. The header and payload are only encoded, not encrypted, so anyone who holds the token can read them, and this tool can decode any token without a key. That also means a decoded payload proves nothing: someone could have edited it. Only a valid signature shows that the token was issued by the holder of the key and has not been modified since. The status line therefore says “Decoded (signature not verified)” until you verify it.

A token with five parts is a JWE (encrypted JWT); its content cannot be read without the decryption key, and the tool tells you so.

Verifying the signature

• HS256, HS384, HS512 (HMAC): enter the shared Secret. Use Secret format to say whether it is plain text (UTF-8) or Base64/Base64url, as some providers store secrets in Base64. You can also paste a JWK of type oct. If the secret is shorter than the hash output (32 bytes for HS256), the tool notes that it is below the RFC 7518 minimum.
• RS256/384/512, PS256/384/512, ES256/384/512 and EdDSA: paste the Public key (PEM or JWK). Accepted PEM blocks are PUBLIC KEY, RSA PUBLIC KEY and CERTIFICATE (the key is read from the X.509 certificate). A JWK or a whole JWK Set works too: the key whose kid matches the header is used. Private keys are refused; a verifier never needs one. EdDSA supports Ed25519 in browsers whose Web Crypto implements it.

Verification uses the browser’s Web Crypto API. A result of “Invalid signature” means the key is wrong or the token was modified. Note that the algorithm is taken from the token header: a real server must instead fix the expected algorithm in its configuration, otherwise an attacker can choose it.

Security notes

• Tokens are credentials. Anyone holding a valid access token can usually act as its owner until it expires. This tool decodes and verifies everything in your browser and never sends the token or the key anywhere. Still avoid pasting production tokens in tools you cannot inspect.
• alg: none means the token is unsigned. Anyone can forge one, and a server must reject it. The tool shows a warning and refuses to “verify” such a token.
• Clock checks here use your computer’s clock without any leeway; servers often allow a minute or two of clock skew.
• JWT dates (NumericDate) are seconds since 1 January 1970 UTC. A 13-digit value is probably in milliseconds, which is a common bug.