Decode JSON Web Tokens instantly — view header, payload and claims in your browser
A JWT consists of a Header, Payload, and Signature — each Base64URL-encoded and joined with dots. The header specifies the algorithm; the payload carries claims; the signature proves authenticity.
Unlike session IDs that require a database lookup, JWTs carry all the information needed for authentication. Servers can validate tokens without shared state, making them ideal for distributed systems.
JWTs are widely used for API authentication (Bearer tokens), single sign-on (SSO), mobile app auth, microservice communication, and as OAuth 2.0 access tokens.
A JSON Web Token (JWT) is a compact, URL-safe token format 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/data), and a signature (proof of authenticity). JWTs are commonly used for API authentication and single sign-on.
This tool runs entirely in your browser — no data is ever sent to any server. However, JWTs often contain sensitive user information and act as authentication credentials. Avoid pasting live production tokens into any online tool. For debugging, use expired tokens or tokens generated against a test environment.
JWT signatures are cryptographic proofs created using a secret key (HMAC) or private key (RSA/ECDSA) that only the issuing server possesses. This tool decodes the Base64URL-encoded header and payload, but cannot verify the signature without the server's secret. Anyone can decode the payload — the signature only guarantees the token wasn't tampered with.
JWT claims are statements about an entity (typically a user) and additional metadata. Registered claims are standardized: iss (issuer), sub (subject), aud (audience), exp (expiration time), iat (issued at), nbf (not before), jti (JWT ID). Public claims are defined in the IANA registry. Private claims are custom application-specific fields agreed upon between parties.
The exp (expiration) claim identifies the time after which the JWT must not be accepted for processing. It is stored as a Unix timestamp (seconds since January 1, 1970 UTC). Servers must reject expired tokens. This decoder converts the Unix timestamp to a human-readable date and shows whether the token has already expired.
Session tokens are opaque random strings stored in a server-side database. Every request requires a database lookup to retrieve user data. JWTs are self-contained — all user data is encoded inside the token. Servers only need the secret key to verify them, with no database required. The tradeoff: JWTs cannot be easily invalidated without a token blocklist, unlike session tokens which can be deleted instantly.
To validate a JWT signature you need the signing secret (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256). Use a server-side library: jsonwebtoken (Node.js), PyJWT (Python), java-jwt (Java), or golang-jwt (Go). Never validate JWTs client-side with a sensitive secret.
Common JWT algorithms: HS256/HS384/HS512 (HMAC-SHA — symmetric, same key signs and verifies), RS256/RS384/RS512 (RSA — private key signs, public key verifies), ES256/ES384/ES512 (ECDSA — smaller signatures than RSA), PS256/PS384/PS512 (RSA-PSS — probabilistic variant of RSA). The alg field in the JWT header identifies the algorithm used.