JWT decoder

Paste a JSON Web Token to read its header and claims, see when it expires, and check an HMAC signature. The token stays in your browser.

Anatomy of a JWT

A JWT (RFC 7519) is three base64url strings joined by dots: a header naming the signing algorithm, a payload of claims, and a signature over the first two. For HS256 the signature is HMAC-SHA256(secret, header + "." + payload) — you can reproduce it with the HMAC generator. RS256 and ES256 use a private key to sign and a public key (often published at a JWKS URL) to verify.

Checks your server should do

  1. Verify the signature with an allow-listed algorithm.
  2. Reject if exp is in the past or nbf in the future (allow a minute of clock skew).
  3. Check iss and aud match what you expect.
  4. Remember the payload is readable by anyone holding the token — keep secrets out of it.

Questions

Is it safe to paste a JWT here?

Decoding happens entirely in your browser; the token is never sent anywhere. Still, a JWT is a bearer credential — prefer pasting test or expired tokens, and never paste production signing secrets into any website.

Does decoding a JWT verify it?

No. Anyone can decode the header and payload — they are only base64url-encoded, not encrypted. Trust a token only after verifying its signature with the secret (HS256) or the issuer's public key (RS256, ES256), and checking exp, nbf, iss and aud.

What do exp, iat and nbf mean?

They are NumericDate claims from RFC 7519, in seconds since 1970-01-01 UTC: exp is when the token expires, iat when it was issued, nbf the time before which it must not be accepted. This page shows them as dates and relative times.

What is the "alg: none" attack?

Some early libraries accepted tokens whose header said alg: none, with no signature at all. Always tell your library which algorithms to accept instead of trusting the header.