Loading…
Loading…
Decode JWT header, payload & expiry — tokens stay private
Token Structure
Run your projects on Claude Code?
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 — $29JSON 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
About the JWT Decoder
Yes. All decoding happens entirely in your browser using JavaScript. Your JWT is never sent to any server. However, avoid pasting production tokens with sensitive permissions in shared environments.
Yes, for HMAC-based JWTs (HS256, HS384, HS512). Enter the secret key and the tool will verify the signature. RSA/ECDSA verification requires the public key.
A JWT consists of three Base64URL-encoded segments separated by dots: header.payload.signature. The header declares the algorithm (alg) and token type (typ). The payload carries the claims (sub, iat, exp, custom fields). The signature is computed over the header and payload using the algorithm and secret.
The exp (expiration time) claim is a Unix timestamp (seconds since January 1, 1970 UTC) after which the token must be rejected. The tool shows a countdown to expiry and a clear EXPIRED badge if the current time exceeds the exp value. Always validate exp server-side — never trust a client-side expiry check alone.
HS256 uses HMAC-SHA256 with a shared secret key — both the issuer and verifier know the same key. RS256 uses RSA asymmetric keys — the issuer signs with a private key and verifiers check with the public key. RS256 is preferred for distributed systems because the public key can be safely shared without compromising signing capability.
Client-side JWT decoding is safe for displaying user information (name, avatar) but must never be used for access control. A malicious user can modify the payload in a decoded JWT. Authorization decisions must always be made server-side by verifying the signature with the secret or public key.
Builder/critic agent prompts with brakes built in
Open →DeveloperFormat, validate & diff JSON — runs entirely in browser
Open →DeveloperTest regex live — railroad diagrams + plain English explained
Open →DeveloperOne color in, full design system out
Open →