JWT decoder with exp, iat, nbf in real time

What's actually inside a JWT

A JSON Web Token is three base64url segments joined by dots: a JOSE header, a payload, and a signature. The header carries the signing algorithm (alg) and the key identifier (kid). The payload is a JSON object of "claims" — facts the issuer asserts about the subject. The signature is what the verifier checks with the issuer's key. Strip the signature off and you can still read both halves. That is what this tool does. It does not, and cannot, prove the token is genuine.

iat, exp, nbf — when they matter and why

Three timestamp claims show up in nearly every real-world token. iat is the moment the issuer minted it. exp is the moment it stops being valid.nbf ("not before") is the moment it starts being valid. Almost every access-token bug a backend engineer hunts down comes from clock skew on one of these three. If your server's clock drifts a minute ahead of the issuer, a token can look "not yet valid" the instant it lands. If it drifts behind, you can accept tokens past their expiry. Most JOSE libraries fix this with a small leeway window — usually 30 to 60 seconds — and that is the right default to copy.

The grid above reads these claims in two ways. The UTC column is the canonical machine-time, useful when you are reading logs. The viewer-zone column is the human-time, useful when you are explaining to a customer why their session ended at 14:03 their time. The relative column ("expired 4 minutes ago") is the one you want at three in the morning when you are debugging a login loop.

Algorithm choice: HS vs RS vs ES vs none

The alg field tells the verifier which cryptography to run. The HS family (HS256, HS384, HS512) is HMAC with a shared secret. Anyone who can verify the signature can also forge new tokens with the same secret, so HS tokens are only safe inside a single trust boundary — a service signing tokens for itself. The RS, PS, ES, and EdDSA families are asymmetric. The issuer keeps a private signing key, publishes the matching public key (usually at a /.well-known/jwks.json endpoint), and any verifier can check the signature without being able to mint new tokens. That asymmetry is what makes federated identity work, and it is the right choice almost everywhere outside a single backend.

alg: none is a special case. It declares that the token is unsigned. It exists in the spec for completeness, and it has been the source of multiple high-profile vulnerabilities where libraries accepted unsigned tokens by accident. Treat any token claiming alg: none as adversarial and reject it at the verifier. The badge above flags this case in red.

Why "decoded" doesn't mean "trusted"

This is the most-misunderstood property of JWTs. The payload is base64url-encoded JSON, not encrypted. Anyone holding the token can read every claim by doing exactly what this tool does. The signature is the only thing that makes the token trustworthy, and verifying it requires the issuer's public key plus a JOSE library that checks alg, exp, nbf, aud, and iss for you. If you are writing the verifier yourself, lean on a well-maintained library (jose for Node and the browser, or the platform equivalent) rather than rolling base64 and signature checks by hand. The footguns are sharp.

If you also need to schedule a meeting around when a token expires, the time zone converter handles the multi-city case nicely. For pure interval arithmetic, the time-since calculator is the simpler shape.