JWT Decoder

JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. It consists of three parts separated by dots: Header contains metadata about the token, specifically the signing algorithm (such as HS256, RS256, ES256) and the token type (always JWT), encoded as Base64Url JSON. Payload contains the claims (statements about an entity, typically the user, and additional data) such as sub (subject/user ID), exp (expiration timestamp), iat (issued at), aud (audience), iss (issuer), and any custom claims your application adds. Signature is computed by hashing the encoded header and payload with a secret key (for HMAC algorithms) or a private key (for RSA/ECDSA algorithms), ensuring the token cannot be modified without detection. The final token looks like: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U.

Decoding is safe because JWT header and payload are NOT encrypted — they are merely Base64Url-encoded (like base64 but URL-safe), meaning anyone who possesses the token can read its contents. This is by design: JWTs are signed (not encrypted) by default. The signature only verifies integrity, not confidentiality. However, you should NEVER share tokens that contain sensitive data (passwords, PII, API keys) in any解码 tool. The security risk is not the decoding itself but exposing the token to third parties. Our tool processes everything client-side in your browser — the token is never sent to any server, maintaining privacy. If your application requires confidential tokens, consider using JWE (JSON Web Encryption) which encrypts the payload, or ensure JWTs do not carry sensitive information.

Common algorithms include: HS256 (HMAC SHA-256) uses a symmetric secret key for signing and verification — the same key signs and validates; HS384 and HS512 use larger hash outputs. RS256 (RSA SHA-256) uses an asymmetric key pair: a private key signs, a public key verifies — used by OAuth providers (Auth0, Okta); RS384 and RS512 are the same with larger hashes. ES256 (ECDSA P-256), ES384, ES512 use elliptic curve cryptography for shorter signatures. None means an unsigned token — reject these in production. The header also sometimes includes kid (key ID) to specify which signing key was used when multiple keys are available alg tokens with algorithm none have been exploited in the past.

Our decoder shows the decoded components and the token's structural validity but cannot fully verify the signature because verification requires the signing secret (for symmetric algorithms like HS256) or the public key (for asymmetric algorithms like RS256). To verify: for symmetric algorithms, enter the shared secret in our signature verification field and the tool will recompute the signature and compare it to the token's signature, indicating match or mismatch. For asymmetric algorithms, provide the public key (PEM format) and the tool performs cryptographic verification. Signature verification confirms two things: the token was signed by the expected issuer (who holds the private key/secret) and the token contents have not been altered since signing. For production token validation, always verify signatures in your authorization middleware.

Standard JWT claims (defined in RFC 7519) include: iss (issuer) identifies the principal that issued the JWT, typically the authentication server URL (like https://auth.example.com); sub (subject) identifies the principal that is the subject of the JWT, typically the user ID; aud (audience) identifies the recipients that the JWT is intended for, typically your application identifier; exp (expiration time) is the timestamp after which the JWT must not be accepted for processing, expressed as Unix epoch seconds; nbf (not before) is the timestamp before which the JWT must not be accepted; iat (issued at) identifies the time at which the JWT was issued, used to determine token age; jti (JWT ID) provides a unique identifier for the JWT, used to prevent token replay attacks. Expiration is the most critical claim: always check exp in your token validation middleware to reject expired tokens.