JWT Decoder

1. Paste your JSON Web Token into the Encoded JWT box at the top. A JWT looks like three base64url-encoded strings joined by dots: header.payload.signature.
2. The decoder runs automatically as you type (debounced 150 ms). The three segments are highlighted in red, purple, and blue above the input box so you can see at a glance which part is which.
3. Read the Header panel for signing metadata (algorithm, token type, key id). Read the Payload panel for the claims — the registered claims iss, sub, aud, exp, iat, and nbf are standardized in RFC 7519.
4. The Token metadata panel below decodes the most common registered claims into human-readable values, including whether the token is currently expired.
5. Use Copy on each panel to grab the JSON output for further inspection or sharing.

The decoder uses the jose library — the same JWT implementation trusted by Auth0, NextAuth.js, Cloudflare Workers, and the OpenID Foundation conformance test suite. Using jose rather than hand-rolled atob decoding guarantees correct handling of URL-safe base64, padding rules, and the JWS Compact Serialization grammar.

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe means of representing claims to be transferred between two parties. Defined in RFC 7519, a JWT consists of three Base64URL-encoded parts separated by dots:

• Header — a JSON object describing the token type (typ: "JWT") and the cryptographic algorithm used to sign it (e.g. HS256, RS256, ES256, EdDSA).
• Payload — a JSON object containing "claims": statements about an entity (typically the user) and additional metadata. Registered claims include iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID).
• Signature — the cryptographic signature computed over the base64url-encoded header and payload, using the algorithm named in the header. The signature is what makes a JWT trustworthy: without the issuer's secret or private key, an attacker cannot produce a valid signature.

JWTs are the dominant authentication token format for modern web and mobile applications. They are used as bearer tokens in OAuth 2.0 and OpenID Connect flows, as session tokens in single-page applications, as stateless authentication tokens in microservice architectures, and as signed payloads in event-driven systems (e.g. Stripe webhook signatures).

No. Decoding simply reverses the base64url encoding — it lets you read the claims but does not prove the token is authentic. Anyone can craft a JWT with any payload they like. Verification requires recomputing the signature with the issuer's secret (for HMAC algorithms) or with the issuer's public key (for RSA, EC, and EdDSA algorithms). This tool intentionally does not verify signatures because verification requires the issuer's secret, which the client should not have. Always verify tokens server-side before trusting their claims.

Yes. This tool runs entirely in your browser; the token is never sent over the network. That said, a JWT is a bearer token — anyone who has it can use it until it expires. If your token is for a production system, prefer decoding it in a private browser session and clear your clipboard afterwards.

JWTs use Base64URL encoding (RFC 4648 §5), which replaces + with -, / with _, and omits trailing = padding. If your token contains + or /, it is not a valid JWT and the decoder will refuse it.

All JWS-standard algorithms: HS256/384/512, RS256/384/512, ES256/384/512, PS256/384/512, and EdDSA. The algorithm shown in the decoded header is informational; the signature segment is opaque to the decoder.