# JWT Decoder

> Free in-browser tool that decodes a JSON Web Token (JWT) and reads its header, payload, and time claims in plain English, with security checks and optional HS signature verification. Everything runs in your browser. Nothing is sent to a server. Independent tool, not affiliated with any token library or vendor. Updated 2026-10-27. Full page: https://lab.awaara.cn/jwt-decoder/

## What it does

- Decoder: paste a full token (header, payload, and signature joined by dots) and read the header and payload as formatted JSON. A leading Bearer word and surrounding quotes are stripped automatically. An empty third part is accepted as an unsigned token.
- Claims table: every payload claim with a plain English meaning. Registered claims (iss, sub, aud, exp, nbf, iat, jti) use the RFC 7519 meanings. Time claims show the raw seconds value, a UTC date, and a relative time (for example, expires in 1 hour).
- Security checks: missing alg, alg none (no signature), missing exp, expired token, token not yet valid (nbf in the future), exp values that look like milliseconds, and notes for shared secret (HS) and public key (RS, ES, PS, EdDSA) tokens.
- HS signature verification (optional, test secrets only): recomputes the HMAC over the original header and payload segments with the Web Crypto API and compares it with the token signature, for HS256, HS384, and HS512. It checks the signature only, not expiry, audience, or issuer.
- Sample token: the public jwt.io demo token (HS256, sub 1234567890, name John Doe, iat 1516239022, no exp claim). It verifies with the secret your-256-bit-secret and triggers the missing exp warning, which is intentional.

## What a JWT is

- A compact, URL-safe token defined by RFC 7519: three base64url segments joined by dots (header, payload, signature) for a signed token. The header names the algorithm and token type. The payload carries claims. The signature is computed over the header and payload with a key.
- A signed JWT is signed, not encrypted. Base64url is an encoding anyone can reverse, so the payload is readable by anyone holding the token. The signature proves the token was not changed and came from the key holder. It does not hide the contents. An encrypted JWT (JWE) has five parts instead of three.
- Decoding is not verifying. A full server side check verifies the signature with a trusted key, then checks the time window (exp, nbf) and that iss and aud match what the service expects. A valid signature alone is not enough, and a readable payload alone proves nothing.
- Common failure modes: a verifier that trusts the header to pick the algorithm can be talked into alg none or into algorithm confusion (RS256 checked as HS256 with the public key as the secret); a short HS256 secret can be brute forced offline from one captured token; a missing exp claim means the token states no expiry of its own.

## Limits

- This page verifies HMAC tokens only (HS256, HS384, HS512). RS256, ES256, PS256, and EdDSA tokens need the signer public key, and this page does not take public keys. Verify those tokens on a server or with a verifier that accepts a public key.
- Time claims are seconds since 1970-01-01 UTC, not milliseconds. A 13 digit exp value is flagged as a likely milliseconds mistake.
- Never paste a production secret or a private key into any web page. If a production secret was exposed, rotate it.

## Sources

- jwt.io, JSON Web Token Introduction: https://www.jwt.io/introduction
- Stytch, A developer guide to RFC 7519, part 1: JWT structure and claims: https://stytch.com/blog/rfc-7519-jwt-part-1/