JWT Decoder

A JSON Web Token (JWT) is a compact, URL-safe string used to securely transmit information between parties as a JSON object. It consists of three Base64URL-encoded parts separated by dots: a Header (algorithm and token type), a Payload (claims), and a Signature. The payload is encoded, not encrypted, so anyone with the token can decode it.

The token is decoded entirely in your browser; nothing is sent to a server. However, JWTs may contain sensitive user data such as user IDs, roles, and email addresses. As a general rule, avoid pasting production tokens from real users into any online tool. Use a test or development token instead.

Claims are key-value pairs in the payload that make statements about the token subject. Registered claims are standard fields defined in RFC 7519: iss (issuer), sub (subject), aud (audience), exp (expiration time), iat (issued at), nbf (not before), and jti (JWT ID). Private claims are any custom fields your application adds, such as user roles or permissions.

The badge shows one of four states based on the exp, nbf, and current time. "Valid" means the token is active and not yet expired. "Expired" means the exp timestamp is in the past and most servers will reject the token. "Not yet valid" means the current time is before the nbf (not before) claim. "No expiry" means the token has no exp claim and never expires on its own.

No. Verifying the signature requires the secret key (for HS256/HS384/HS512) or the public key (for RS256/ES256) used when the token was signed. This JWT decoder only decodes the header and payload, which are Base64URL-encoded, not encrypted. Anyone with the raw token string can decode them. The signature segment is shown as-is for reference.

Common algorithms include HS256 (HMAC-SHA256, symmetric), HS384, HS512, RS256 (RSA-SHA256, asymmetric), RS384, RS512, ES256 (ECDSA-SHA256, asymmetric), ES384, ES512, and PS256 (RSA-PSS). The algorithm is declared in the header alg field. For new projects, RS256 or ES256 is generally preferred over HS256 because they use separate signing and verification keys.

A traditional session token is an opaque random string that maps to server-side session data. A JWT is self-contained: all the user information lives inside the token itself. This makes JWTs stateless and easy to use across microservices, but it also means a JWT cannot be invalidated server-side without additional infrastructure (a blocklist or short expiry windows).

The nbf (not before) claim sets an earliest time before which the token must not be accepted. If the current time is before the nbf timestamp, the status shows "not yet valid." This is useful for issuing tokens that activate at a future point, or for clock-skew tolerance between servers.

Standard JWTs (JWS) sign the payload but do not encrypt it. The payload is only Base64URL-encoded, so anyone who intercepts the token can read the claims. If you need encryption, use JWE (JSON Web Encryption), which wraps an encrypted payload. Never store passwords, credit card numbers, or other secrets in a standard JWT payload.

Split the JWT string on the dots to get three segments. Take the second segment (payload) and Base64URL-decode it: replace - with + and _ with /, pad to a multiple of 4 with =, then run through a standard Base64 decoder. The result is the raw JSON payload. The same process works for the first segment (header).