JWT Decoder & Verifier

Paste a JSON Web Token to read its header and payload, see when it expires, and optionally verify the HMAC signature with your secret. Everything runs in your browser — the token is never uploaded. Last reviewed 2026-06-19.

What a JWT is

A JSON Web Token (JWT, pronounced “jot”) is a compact, URL-safe way to carry claims between two parties — most often a sign-in token your app receives after a user authenticates. It has three parts separated by dots: header.payload.signature. The header and payload are JSON objects that are only Base64URL-encoded, so they are readable by anyone — the signature is what proves the token has not been changed and was issued by someone holding the key.

The three parts

  • Header — the signing algorithm (alg, e.g. HS256 or RS256) and token type (typ).
  • Payload — the claims: who the token is about, who issued it, when it expires, and any custom data.
  • Signature — a keyed hash of header.payload. For HMAC it uses a shared secret; for RSA/ECDSA it uses the issuer’s private key and is checked with the matching public key.

Registered claims

ClaimNameMeaning
issIssuerWho issued the token (the authorization server / app).
subSubjectWho the token is about — usually the user ID.
audAudienceWho the token is intended for; the recipient must reject it if it is not the audience.
expExpirationUnix time after which the token must not be accepted. Decoded to a human time below.
nbfNot beforeUnix time before which the token must not be accepted.
iatIssued atUnix time the token was issued.
jtiJWT IDA unique identifier, used to prevent replay.

Verifying the signature

Verification recomputes the signature over the first two segments and checks it matches the third. This tool verifies the HMAC family (HS256, HS384, HS512) when you provide the shared secret, using the browser’s native crypto.subtle. Asymmetric tokens (RS256, ES256, PS256) are decoded fully, but their signatures can only be verified with the issuer’s public key (from its JWKS endpoint), so they are not checked here. A decoded token is never proof of validity — always confirm exp, nbf, aud and iss too.

Worked example

The classic RFC 7519 sample token below uses HS256 with the secret your-256-bit-secret. Its header decodes to {"alg":"HS256","typ":"JWT"} and its payload to {"sub":"1234567890","name":"John Doe","iat":1516239022} — that iat is 23 January 2018. Click Load example above to decode and verify it instantly.

Frequently asked questions

Is my token uploaded anywhere?
No. Decoding and signature verification happen entirely in your browser using the built-in Web Crypto API. The token and the secret never leave your device and are never logged or transmitted — so it is safe to inspect tokens that would be risky to paste into a server-side tool. It also works offline once the page has loaded.
Is a decoded JWT secret or encrypted?
No. A standard JWT is signed, not encrypted — the header and payload are only Base64URL-encoded, so anyone holding the token can read them. The signature does not hide the contents; it only proves the token was not tampered with and was issued by someone who knows the key. Never put secrets you would not want a client to see inside a JWT payload.
Which signatures can this tool verify?
It verifies HMAC signatures — HS256, HS384 and HS512 — when you supply the shared secret, using the native Web Crypto API. Asymmetric algorithms (RS256, ES256, PS256, EdDSA) are still fully decoded, but their signatures are validated with the issuer’s public key, which only the issuer’s well-known endpoint has, so this tool does not verify them.
What does "expired" mean here?
If the payload has an exp (expiration) claim and that moment is in the past compared with your device clock, the token is shown as expired. Likewise a nbf (not-before) claim in the future is shown as not yet valid. These are read straight from the decoded claims; expiry checking is normally done by the server that receives the token.
Why is the signature "valid" but the server still rejects my token?
A valid signature only means the token was not altered and the key matches. The server may still reject it because it is expired (exp), used too early (nbf), has the wrong audience (aud) or issuer (iss), or was revoked. Check those claims in the decoded payload too.

Related tools

See all browser tools → · All developer & data conversions →