JWT Decoder

// HOW TO USE

1. 01Paste a JWT into the input. JWTs are three Base64url segments joined by . — header.payload.signature.
2. 02Header contains the algorithm (alg) and token type (typ).
3. 03Payload holds the claims — common ones are sub, iat, exp, plus any custom application claims.
4. 04Signature is a cryptographic signature over header + payload — shown as raw bytes in hex. Verifying it requires the secret/key, which this tool does not handle.

// WHEN TO USE

Use this when debugging authentication failures, inspecting what claims a token carries, or verifying that a backend issues tokens with the correct exp, sub, aud, and custom claims. Paste the raw JWT from an Authorization header, a cookie, or a network tab — the decoder splits the three Base64url segments and displays each as formatted JSON. Note: this tool only decodes and displays; it does not verify the signature, so do not use it to make security trust decisions — it is for inspection and test debugging only.

// WHAT BUGS THIS FINDS

• Expired token in test fixture

  A test fails with a 401 because a hardcoded JWT in a fixture has expired — decode it to read the exp claim and confirm the Unix timestamp has passed.

• Missing or incorrect claims

  A backend issues a token without a required claim (e.g. role, tenant_id) — decode the actual token from a test run to confirm the claim is absent before filing the bug.

• Wrong audience or issuer

  An API returns 403 despite a valid token — decode to check the aud and iss claims against what the API expects; a value mismatch is the most common root cause.

• Algorithm confusion in header

  The alg claim in the header shows 'none' or an unexpected algorithm — decoding the header exposes this before it becomes a security finding in a production code review.

// QA USE CASES