JWT Decoder & Verifier

About JSON Web Tokens (JWT)

A JSON Web Token is a compact, URL-safe way to carry claims between two parties. It is made of three Base64URL-encoded segments joined by dots: header.payload.signature. The header describes the signing algorithm, the payload holds the claims (who the token is about, when it expires, what it grants), and the signature lets the receiver confirm the token has not been tampered with. JWTs are the default session and API-authorization format for OAuth 2.0, OpenID Connect, and most modern single-page and mobile applications.

What This Decoder Shows You:

• Header: The algorithm (alg), token type (typ), and key identifier (kid) used to sign the token.
• Payload: Every claim, pretty-printed as JSON and also broken out into a readable table.
• Human-readable times: exp, iat, and nbf are converted from Unix seconds into absolute UTC timestamps plus a relative age, so an expired token is obvious at a glance.
• Security notes: Warnings for alg: none, missing expiry, and tokens that are not yet valid.
• Signature verification: Supply the shared secret and the tool verifies HS256, HS384, and HS512 signatures with the browser's built-in Web Crypto API. The bundled sample token verifies with the secret your-256-bit-secret.

Registered Claims Explained:

• iss (issuer): Who created and signed the token.
• sub (subject): Who the token is about — typically a user identifier.
• aud (audience): The recipient the token is intended for. Always validate this server-side.
• exp (expiration): Seconds since the Unix epoch after which the token must be rejected.
• nbf (not before): The token is invalid before this time.
• iat (issued at): When the token was created — useful for enforcing a maximum token age.
• jti (JWT ID): A unique identifier, used to prevent token replay.

JWT Security Pitfalls to Watch For:

• The alg: none attack: An attacker strips the signature and sets the algorithm to none. Libraries that trust the header will accept the forged token. Always pin the expected algorithm on the server rather than reading it from the token.
• Algorithm confusion (RS256 to HS256): If a server accepts whatever algorithm the header names, an attacker can sign a token with the public RSA key treated as an HMAC secret. Use an explicit allow-list.
• Weak HMAC secrets: Short or dictionary secrets are brute-forceable offline once a token leaks. Use a long, random secret.
• The payload is not encrypted: Base64URL is encoding, not encryption. Anyone holding the token can read every claim — never put passwords, keys, or sensitive personal data in a JWT.
• Missing or long expiry: A token without exp, or with a multi-month lifetime, stays useful to an attacker long after it leaks. Keep access tokens short-lived and use refresh tokens.

Common Use Cases:

• API debugging: Check which claims and scopes a token actually carries when a request returns 401 or 403.
• Expiry troubleshooting: Confirm whether an intermittent auth failure is simply an expired token.
• Security review: Inspect the algorithm, key ID, and audience of tokens issued by your identity provider.
• Learning and integration work: See exactly what an OAuth or OpenID Connect provider puts into its ID and access tokens.

Because this decoder is fully client-side, the token and any secret you enter are processed in your browser using JavaScript and the Web Crypto API. Nothing is transmitted to a server, logged, or stored — which matters, since a live access token is a credential. Even so, treat production tokens with care and rotate anything you suspect has been exposed.