JWT Decoder & Verifier

What's inside a JSON Web Token?

A JWT is three base64url-encoded segments joined by dots: a header naming the signing algorithm, a payload of claims, and a signature over the first two segments. Nothing about it is encrypted — base64url is an encoding, not a cipher — which is why a decoder needs no keys and why you should never put secrets in a payload.

Claims follow RFC 7519: registered names like iss (issuer), sub (subject), aud (audience) and the three time claims iat, exp and nbf, expressed as Unix epoch seconds. This decoder labels the registered claims and converts the time claims to your local timezone with a relative offset, which turns debugging "401 Unauthorized" loops into a two-second glance.

Decoding vs. verifying — the distinction that matters

Anyone can decode a JWT; only a holder of the right key can verify one. Verification recomputes the signature — built per RFC 7515, the JSON Web Signature spec a JWT's third segment follows — over the header and payload and compares it against that segment. With HS* algorithms the same secret signs and verifies; with RS*/ES* the issuer signs with a private key and you verify with the public one.

This page verifies HS256, HS384, HS512 and RS256 — the four algorithms behind the overwhelming majority of real-world tokens — using WebCrypto in your browser. Treat the result the way your API gateway would: an invalid signature means the token was tampered with, signed by someone else, or corrupted in transit.

Worked example

This is the canonical HS256 demo token from jwt.io — the same value the Sample button loads in the decoder above. Its three base64url segments decode to the header and payload shown here.

{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}