Decode a JWT Authentication Token

JSON Web Tokens (JWTs) are the backbone of modern authentication in REST APIs, OAuth 2.0, and OpenID Connect. When a user authenticates with your application, an auth server issues a signed JWT that the client includes in subsequent API requests. The server validates the signature and reads the claims to know who the user is and what they're authorized to do — without making a database lookup on every request. This stateless approach is why JWTs are so widely adopted. This example contains a JWT issued by an RS256-signed token (RSA asymmetric signing, common in production systems). The header declares the algorithm (RS256), token type (JWT), and a key ID (kid) that tells the verifier which public key to use for signature verification. The payload contains the standard claims: sub (subject — the user identifier), iss (issuer — the auth server URL), aud (audience — which API this token is for), iat (issued-at), exp (expiration), scope (authorized OAuth scopes), and role (a custom claim for authorization). Debugging authentication failures with the JWT decoder: the most common JWT-related bugs are expired tokens (compare exp to current timestamp), wrong audience (aud doesn't match what your API expects), wrong issuer (iss doesn't match your configured auth server URL), missing scopes (the scope claim doesn't include the scope required by the endpoint), and role mismatch (user has role "editor" but endpoint requires "admin"). The decoder surfaces all of these immediately. RS256 vs HS256: this example uses RS256, the recommended algorithm for production systems. RS256 uses RSA asymmetric key pairs — the auth server signs with the private key and any service can verify with the public key. This means multiple services can independently verify tokens without sharing a secret. HS256 uses a symmetric secret that must be shared securely with every service that verifies tokens, creating key distribution complexity. The kid (key ID) in the header is used for key rotation: when the auth server rotates its signing keys, it uses the kid to indicate which key signed the token. Services fetch the auth server's JWKS (JSON Web Key Set) endpoint and use the matching key to verify the signature. Without kid, key rotation is painful. Security note: this decoder runs entirely in your browser — no data is sent to any server. However, as a general security practice, avoid pasting real long-lived production tokens into any online tool. Short-lived tokens (5-minute expiry) that have already expired are safe to inspect without concern.

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImFiYzEyMyJ9.eyJzdWIiOiJ1c2VyXzQ1NiIsImlzcyI6Imh0dHBzOi8vYXV0aC5leGFtcGxlLmNvbSIsImF1ZCI6ImFwaS5leGFtcGxlLmNvbSIsImlhdCI6MTcwMDAwMDAwMCwiZXhwIjoxNzAwMDAzNjAwLCJzY29wZSI6InJlYWQ6cHJvZmlsZSB3cml0ZTpwb3N0cyIsInJvbGUiOiJlZGl0b3IiLCJlbWFpbCI6InVzZXJAZXhhbXBsZS5jb20ifQ.signature