JWT Decoder splits the token on its two dots, base64url-decodes the first two segments and parses each as JSON. Padding is restored before calling atob() so URL-safe tokens with stripped = signs work without errors. The header and payload are pretty-printed; exp and iat claims (Unix seconds) are formatted as local timestamps so you can see at a glance whether the token is still valid.
Crucially this is a decoder, not a verifier — the signature segment is shown as raw base64url because checking it requires the issuer's HMAC secret or public key, which the browser does not have. Decoding is safe for untrusted tokens (no code runs), but never paste a production token from a system you do not trust into any third-party site. Everything in this page runs locally.
No. Verification needs the issuer's secret (HS*) or public key (RS*/ES*/PS*). Decoding only reveals what the token claims; trust still requires checking the signature on your server with the right key and algorithm.
Base64url (RFC 4648 §5) without padding — the URL-safe variant where + becomes -, / becomes _, and trailing = signs are stripped. The decoder restores padding before calling atob() to handle that.
If the payload contains an exp claim (Unix seconds), the decoder compares it to the current device time. A token can also appear expired if your system clock is wrong — JWTs use UTC seconds, so timezone is not the issue.
No. The header and payload are only base64url-encoded, not encrypted — anyone with the token can read them. Never put passwords or PII into a JWT payload; that is what JWE (encrypted JWTs) is for.
Explore the full suite of Security tools and 290+ other free utilities at Chunky Munster.
📖 Reference: RFC 7519 — JSON Web Token (JWT)