JWT Decoder

Paste the JWT into the input field and the tool decodes it instantly. A JWT is three Base64url-encoded segments separated by dots. This tool splits them, decodes each segment, and displays the header and payload as formatted JSON. No secret key is required for decoding. You only need a secret to verify the signature.

A session cookie stores a session ID on the client and the actual session data lives on the server. On every request, the server looks up the session ID in a database or cache. A JWT stores all the claims directly in the token itself. The server can verify the token and read the claims without a database round-trip, making JWTs well-suited for distributed and stateless architectures.

Yes. This tool runs entirely in your browser. Your JWT is never sent to any server. All Base64url decoding and JSON parsing happens locally in JavaScript. As a general habit, avoid pasting live production tokens into any online tool. Use them only in trusted, browser-local environments like this one.

No. Decoding a JWT only requires Base64url decoding and needs no secret. Verifying the signature requires the original HMAC secret (for HS256/HS512) or the public key (for RS256/ES256). This tool shows the signature bytes but cannot verify authenticity. Use the JWT Generator tool for signing and verification.

RFC 7519 defines several registered claim names: iss (Issuer), sub (Subject), aud (Audience), exp (Expiration Time), nbf (Not Before), iat (Issued At), and jti (JWT ID). All other claims in the payload are private or public claims defined by the application.

The exp claim is a Unix timestamp (seconds since January 1, 1970 UTC). If the current time is past that value, the token is expired. Many JWTs have short lifetimes (15 minutes for access tokens). If you are debugging a production issue with an expired token, the timestamp shown will help you understand when the token was valid.

Common values for the alg header claim: HS256, HS384, HS512 (HMAC with SHA-2, symmetric), RS256, RS384, RS512 (RSA with SHA-2, asymmetric), ES256, ES384, ES512 (ECDSA, asymmetric), and none (no signature). The alg none variant is a known security risk and should be rejected by properly configured libraries.

Yes. All standards-compliant JWTs from any provider follow the same header.payload.signature format. Paste the token and this tool will decode the header and payload regardless of the issuer or platform.

Yes, as long as the token is a JWT. Many OAuth providers (including Auth0, Okta, and Azure AD) issue access tokens and refresh tokens as JWTs, and 'bearer token' just describes how the token is sent, in an Authorization: Bearer header, not a different token format. Paste it in and this tool decodes the header and payload the same way it would for any other JWT. Opaque tokens (a random string with no dots) are not JWTs and can't be decoded this way, since there's nothing encoded in them to read.

JWS (JSON Web Signature, RFC 7515) is the general signing format: a header, a payload, and a signature. A JWT is a JWS (or occasionally a JWE, the encrypted variant) whose payload follows the specific claim structure defined in RFC 7519. In practice, when someone says JWT, they almost always mean a signed JWS with standard claims, which is exactly what this tool decodes.