Token Structure
JSON Web Tokens (JWTs), defined in RFC 7519, are a compact, URL-safe token format used for authentication and information exchange. A JWT encodes claims — assertions about an entity — in a JSON payload that is Base64URL-encoded and signed using HMAC-SHA256 (HS256), RSA (RS256), or ECDSA (ES256). During debugging, inspecting a JWT's header algorithm, payload claims, expiry time, and signature validity without writing code saves significant time. The decoder handles all three JWT segments and surfaces the human-readable interpretation of every standard claim.
A JWT arrives as three Base64URL-encoded segments concatenated with dots. Base64URL encoding is the standard Base64 alphabet (defined in RFC 4648 Section 5) with + replaced by - and / replaced by _ to make the output safe for URL and HTTP header use. The tool splits on the dot delimiter and applies atob() after re-padding the Base64URL segments to standard Base64 with = characters.
The decoded header JSON identifies the signing algorithm and key ID. The decoded payload JSON is parsed and each standard claim (iss, sub, aud, exp, nbf, iat, jti) is displayed with its semantic meaning alongside the raw value. Unix timestamps for exp and iat are converted to human-readable dates and the time-to-expiry is computed from the current browser time.
For HMAC verification (HS256, HS384, HS512), the tool recomputes the signature over the raw header.payload bytes using the Web Crypto API's HMAC-SHA-256/384/512 implementation and compares the result to the signature segment. A match confirms the token is authentic and untampered.
A backend developer debugging an authentication failure decodes the JWT from a failing API request to check whether the sub or roles claims match what the authorization middleware expects.
A developer integrating a third-party OAuth provider inspects the ID token to understand which claims are included and verify the exp timestamp is reasonable.
A security engineer audits a JWT and finds the alg header is set to "none" — a known JWT attack vector — catching a misconfiguration before it reaches production.
An API developer verifies that a webhook JWT from a payment provider validates against the expected HMAC secret before shipping the integration.
Scope note: This tool verifies HMAC signatures (HS256/HS384/HS512) using the Web Crypto API. RSA (RS256, RS512) and ECDSA (ES256, ES384, ES512) verification requires the public key in PEM or JWK format — enter it in the verification field. Never use this tool to decode tokens containing PII (personally identifiable information) in shared or public environments. Production systems must always verify signatures server-side; client-side decoding is for inspection only.
Paste your JWT token in the input field
Inspect decoded header and payload claims instantly
Check token expiry time and 'issued at' claim
Optionally enter a secret to verify HMAC signature
We packaged the .claude config that runs this site — 26 specialist agents, 14 workflow skills, and 6 rule files from 31 real production incidents. From $9.
Get the Claude Code Production Pack — $29