JWT Decoder & Validator

Last reviewed on 4 May 2026.

Paste a JWT to decode its header and payload. Add a secret or public key to verify the signature. Everything runs in your browser — no token ever leaves this page.

Privacy: This tool runs entirely in your browser using the Web Crypto API. The JWT, secret, and public key are never sent to any server. View source to verify; the implementation is in this single HTML file with no external dependencies.

Input

Paste a token to decode immediately. Decoding is local; nothing is transmitted. Plain text. Treated as UTF-8 bytes for HMAC computation. PEM-format SubjectPublicKeyInfo. The header's alg determines which key type is expected.

Decoded

Header
—
Payload
—
Claims
—
Signature
—
Verification
No verification performed yet. Add the secret or public key and click "Verify signature."

What this tool does, and what it doesn't

It decodes the three base64-encoded segments of a JWT and shows you the parsed header and payload. It computes claim metadata — when the token expires, when it was issued, what algorithm signed it — and warns about common problems. With a secret or public key, it verifies that the signature is valid.

It does not do the things a real verifier on your server has to do: enforce that the algorithm matches what your application expects (preventing the algorithm-confusion attack), check that the issuer and audience match what you configured, validate against a JWKS endpoint, or check token revocation. Use this tool to inspect tokens during development; do not copy its decode logic into production code without understanding what's missing.

What's in a JWT

A JWT is three base64url-encoded segments separated by dots: header.payload.signature.

  • The header is a JSON object describing how the token was signed — typically alg (algorithm) and typ (always "JWT").
  • The payload is a JSON object of claims — statements about the subject of the token.
  • The signature is computed over the encoded header and payload using the algorithm in the header.

The standard claims, with what they actually mean

The JWT spec defines a small set of registered claim names. Most production JWTs use a subset of these plus application-specific claims.

  • iss — issuer. Who minted the token. Your verifier should require this match an expected value; trusting any issuer defeats the point.
  • sub — subject. The principal the token is about, usually a user ID. The string the token authorizes you to act as.
  • aud — audience. Who the token is intended for. A token issued for service A should be rejected by service B even if the signature is valid.
  • exp — expiration time. Unix timestamp after which the token must not be accepted. Verifiers should enforce a small clock-skew tolerance (typically 30–60 seconds).
  • nbf — not before. The token is invalid before this time. Useful for tokens issued ahead of when they become valid.
  • iat — issued at. When the token was created. Not a security control by itself; informational.
  • jti — JWT ID. A unique identifier for the token. Used by revocation lists and for deduplicating one-time tokens.

The mistakes this tool is designed to surface

  • alg: "none" — a token claiming to be unsigned. Some libraries historically accepted these. Reject any token whose algorithm doesn't match what your application expects.
  • Algorithm confusion — an HS256 token signed with the public RSA key. If your verifier accepts both algorithms and uses the same key material, an attacker can forge tokens. Pin the algorithm in your verifier.
  • Missing or expired exp — tokens with no expiry become permanent credentials when they leak.
  • Missing iss or aud — tokens that don't say who issued them or who they're for can sometimes be replayed across services that share signing keys.
  • Sensitive data in the payload — the payload is base64-encoded, not encrypted. Anyone who sees the token can read it.

For the broader picture on JWT design — when to use them, when to use opaque tokens instead, and how to handle revocation — see the authentication reference.

Where to go next

For implementation patterns around tokens — secret storage, rotation, recovery from compromise — see the authentication guide. For the broader security model that surrounds authentication, see API security.