The three parts of a JWT

A JSON Web Token is three Base64URL-encoded segments joined by dots: a header describing the signing algorithm and token type, a payload holding the claims (the actual data — user ID, expiry, roles, whatever the issuer put there), and a signature. The header and payload are just JSON underneath the encoding, which is why this tool can decode them instantly and locally — Base64URL is not a secret encoding, it's a text-safe transport format. Anyone with the token can read the header and payload; there is no confidentiality step involved in decoding them.

Why this tool can't verify the signature — and why that matters

The signature is what actually proves a token wasn't tampered with, and checking it requires the issuer's secret (for HMAC algorithms like HS256) or public key (for RSA/ECDSA algorithms like RS256/ES256) — neither of which this tool has, and neither of which should ever be pasted into a browser tool. That means "decoding" a JWT here tells you what the claims say, not whether they're genuine. A tampered or entirely fabricated token will decode into perfectly normal-looking JSON. This distinction matters most when debugging an auth integration: if a request is being rejected, decoding the token here can confirm what claims and expiry it actually contains, but the actual pass/fail verification has to happen wherever the real signing key lives.

Reading the time-based claims

`exp` (expiration), `iat` (issued at), and `nbf` (not valid before) are the three standard time claims, stored as Unix timestamps (seconds since epoch, not milliseconds — a common source of off-by-1000x bugs when handling them manually). This tool converts each one to a local date/time automatically when present, and flags `exp` as expired or still valid against the current time, which is usually the fastest way to confirm "is this token why the request is failing" during a debugging session.