JWT Decoder & Token Inspector

How to use the JWT decoder

JWTs are everywhere — OAuth bearer tokens, Auth0/Cognito sessions, signed API requests. The decoder splits a token into its three Base64-URL parts (header, payload, signature) and shows the claims human-readably. Decoding happens entirely in your browser; tokens never leave the page.

• 1. Paste the JWT into the input field. Format is header.payload.signature, three Base64URL strings separated by dots.
• 2. Read the decoded header to see the algorithm (HS256, RS256, ES256) and key ID (kid) if present.
• 3. Inspect the payload claims: iss (issuer), sub (subject), exp (expiration), iat (issued at), aud (audience), plus any custom claims your auth provider added.
• 4. Check the expiration timestamp. The decoder converts exp/iat/nbf from Unix seconds to readable local time and flags expired tokens.
• 5. Copy individual claims with one click for use in tests, support tickets, or curl commands.

Common JWT mistakes to avoid

• Trusting the payload without verifying the signature. The decoder just decodes — it does not verify. Anyone can forge a JWT body. On the server, always verify the signature with the issuer's public key (or HMAC secret).
• Storing secrets in JWT payloads. Bodies are Base64-encoded, not encrypted. Anyone reading the token sees the contents. Use JWE (encrypted JWT) for sensitive claims, or store them server-side.
• Forgetting to set exp. Tokens without expiration live forever — a leaked token is permanent compromise. Set short exp (5–60 minutes) and rotate refresh tokens.
• Using alg: none in production. A 2015 vulnerability — accepting unsigned tokens lets anyone forge any identity. Always whitelist allowed algorithms.
• HS256 with a weak secret. Anything under 32 random bytes is brute-forceable. Use 256-bit random keys, or switch to RS256/ES256 for asymmetric signing.
• Not validating iss and aud. A token signed for service A can be replayed against service B if both share the secret and don't check the audience.