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
| Claim | Name | Meaning |
|---|---|---|
iss | Issuer | Who issued the token (the authorization server / app). |
sub | Subject | Who the token is about — usually the user ID. |
aud | Audience | Who the token is intended for; the recipient must reject it if it is not the audience. |
exp | Expiration | Unix time after which the token must not be accepted. Decoded to a human time below. |
nbf | Not before | Unix time before which the token must not be accepted. |
iat | Issued at | Unix time the token was issued. |
jti | JWT ID | A 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 →