JWT Decoder & Verifier
Decode a JWT in the browser: header, payload and claims explained, exp/nbf/iat as UTC dates with expiry status; verify HS/RS/PS/ES signatures with your own key.
The algorithm, the claims with their meaning and readable times, whether the token is valid, expired or not yet valid, and — with a secret or public key you keep on your machine — whether the signature checks out.
Example: An HS256 token with iss, sub, aud, iat, nbf, exp and scope decodes to eight claims; exp 4102444800 reads 2100-01-01T00:00:00Z, and the signature verifies against the secret "arzentiq-demo".
Readable by anyone,
trusted by no one.
What the three parts of a token are, why decoding proves nothing, how the time claims are read, and how verification works without the key ever leaving your machine.
Three parts, two of them plain text
A signed JWT (RFC 7519, RFC 7515) is header.payload.signature, each part base64url — an encoding, not encryption. The header names the algorithm and key; the payload holds the claims; the signature covers the first two parts exactly as written. Decoding reverses the encoding and parses the JSON. Anyone holding the token can do it, which is why a token must never carry secrets in its claims.
The claims and the clock
Registered claims (RFC 7519 §4.1) are explained inline: iss, sub, aud, exp, nbf, iat, jti, plus common OpenID and OAuth ones. Time claims are seconds since 1970-01-01 UTC; the page shows the UTC date and the distance from your device clock, and flags values that look like milliseconds. "Expired" and "not yet valid" follow the claims literally — servers usually allow a small clock skew, which is their policy, not the token's.
Verification
Verification recomputes the signature over header.payload with the browser's Web Cryptography API: HMAC (HS256/384/512) with the shared secret, or RSA (RS/PS) and ECDSA (ES256/384/512) with the issuer's public key in PEM (SPKI) form. ECDSA signatures are the raw r‖s concatenation JWS requires (RFC 7518 §3.4). The key is used in memory on this page and is not sent anywhere; still, an HMAC secret is the signing key itself — paste production secrets only on a machine you trust.
What the tool does not settle
It does not fetch keys from a JWKS URL, decrypt JWE tokens (five parts), or judge whether the issuer and audience are the ones your application expects — those checks belong to the receiving service (RFC 8725). alg "none" is reported as unsecured, never as valid. The same four anonymous usage counts as the rest of the site apply.
SOURCES
- RFC 7519 — JSON Web Token (JWT): registered claims §4.1
- RFC 7515 — JSON Web Signature (JWS): compact serialisation
- RFC 7518 — JSON Web Algorithms (JWA): HS/RS/PS/ES
- RFC 8725 — JSON Web Token Best Current Practices
- W3C Web Cryptography API — SubtleCrypto.verify
Last reviewed 18 September 2026. How results are checked: How we verify.