Paste a JWT to inspect the header and payload. Expiry is evaluated client-side from the exp claim when present. Signature verification needs your secret or public key and is not performed here.
Need more than a template?
I build internal tools, integrations and full-stack products for startups and growing teams.
Full-stack engineering →A JSON Web Token is three base64url strings joined by dots: a header, a payload and a signature. This tool decodes the header and payload so you can read the claims, and it tells you whether the exp claim has passed. It does not verify the signature. Verifying needs the secret or public key, so a decoded token is not proof that the token is genuine.
{"alg":"HS256","typ":"JWT"}HS256 means one shared secret both signs and verifies the token. RS256 means a private key signs it and a public key verifies it.
{"sub":"1234567890","iss":"https://auth.example.com","aud":"my-api","iat":1893452400,"exp":1893456000}exp 1893456000 is 1 January 2030, 00:00:00 UTC. The value counts seconds since 1970.
Anyone can build a token with any claims they like. Your API has to verify the signature, the issuer, the audience and the expiry before it believes the payload.
The payload is encoded, not encrypted. Whoever holds the token can read it, so keep passwords and personal data out.
exp and iat are in seconds. JavaScript's Date.now() returns milliseconds. A token that seems to expire in the year 50000 usually has this bug.
Fix the allowed algorithms in your server configuration. If the verifier trusts the alg value in the header, an attacker picks the weakest one.
A token that fails as expired or not yet valid by a few seconds usually points to two clocks that disagree. Most libraries accept a small leeway, often 30 to 60 seconds.