Paste a JSON Web Token to read its header and claims, and see when it was issued and when it expires. Decoding happens locally.
Runs in your browser — nothing is uploaded
This tool decodes the token only. It does not verify the signature, so do not trust any claim until your server has verified the token with the correct key.
A JSON Web Token has three Base64URL parts separated by dots: a header describing the signing algorithm, a payload carrying claims such as the subject and expiry, and a signature. The first two parts are plain JSON once decoded, so you can read them without any key.
Time-based claims are stored as Unix timestamps in seconds. iat is when the token was issued, nbf is the earliest moment it is valid, and exp is when it stops being accepted. The decoder converts them to UTC dates and shows how long a live token has left.
Decoding is not verification. Anyone can read a JWT, but only a party that holds the signing key can confirm the content was not changed. Use this page for debugging and inspection, and keep production tokens out of screenshots and shared chat.
No. The token is split and decoded with JavaScript in your browser, and the page makes no request containing its contents. A token is still a credential, so avoid pasting a live production token into any site you do not control.
The header and payload are only Base64URL-encoded, not encrypted. The signing key produces the signature, which proves integrity. Reading the claims needs no key, but trusting them requires verifying the signature with the correct secret or public key.
iat (issued at) records when the server created the token, nbf (not before) is the earliest time it should be accepted, and exp (expiration time) is the cut-off. All three are seconds since 1 January 1970 UTC, as defined in RFC 7519.
The exp value is absolute, so a token with a short lifetime expires quickly, and clock skew between servers can make a fresh token look old. Compare the exp date with the current UTC time rather than your local time zone.
Not unless the server expects unsigned tokens. A token with alg set to none carries no signature, so the receiving application must reject it unless it has an explicit allow-list. Decoding one here is fine for inspection, but never accept it without checks.
No. Verification needs the shared secret for HS256 or the public key for RS256 and ES256. Use a JWT library on your server, which checks the signature, expiry and audience together.