JWT Decoder

JWT (JSON Web Token) is a compact, URL-safe token format used for authentication and authorization in web applications and APIs. A JWT has three Base64URL-encoded segments separated by dots: header.payload.signature. The header describes the signing algorithm (e.g., HS256 for HMAC-SHA256 or RS256 for RSA). The payload contains claims - JSON key-value pairs like {"sub":"user123","exp":1700000000,"role":"admin"}. The signature is computed from the header and payload using a secret key (for HMAC) or a private key (for RSA), and it proves the token has not been tampered with.

This tool decodes the header and payload by splitting the JWT on dots, Base64URL-decoding the first two segments, and parsing them as JSON. The decoded JSON is pretty-printed so you can inspect claims like user ID (sub), expiration (exp), issuer (iss), and custom claims. All decoding happens in your browser - the JWT is never uploaded to a server. This is important for security: JWTs often contain sensitive information and can grant access to APIs or user accounts if leaked. Never paste production JWTs into untrusted online tools that may log or store tokens.

This tool does NOT verify the JWT signature. Signature verification requires the secret key (for HMAC) or public key (for RSA), which the browser does not have. Without signature verification, a decoded JWT cannot be trusted for authentication or authorization. An attacker could create a fake JWT with claims like {"sub":"admin","exp":9999999999} and this tool would decode it successfully, even though it is not signed by the real server. Always verify JWTs on the server side before trusting the claims. Use this tool only for debugging and inspecting JWTs during development.

The tool also does NOT validate the exp (expiration) or nbf (not before) claims. An expired JWT will decode successfully and show the expired timestamp. You must check the exp claim yourself and compare it to the current Unix timestamp. JWE (JSON Web Encryption) tokens, which have five Base64URL segments instead of three, are not supported. This tool only handles JWS (JSON Web Signature) tokens with the compact serialization format (three segments).

Worked example: A developer is integrating with a third-party API that returns a JWT access token. The API documentation says the token contains a "userId" claim, but the developer is not sure if the token is structured correctly. The developer pastes the JWT into this tool and sees the decoded payload: {"sub":"abc123","userId":"user_456","exp":1700000000,"iss":"api.example.com"}. The userId claim is present, so the developer can proceed with the integration. Because the decoding was done locally in the browser, the JWT (which grants access to the developer's test account) never left the developer's laptop.