JWT Decoder

A JSON Web Token (JWT) is an open standard (RFC 7519) for securely transmitting information between parties as a compact, URL-safe JSON object. A JWT consists of three Base64URL-encoded parts separated by dots: a header (specifying the algorithm and token type), a payload (containing claims about the user or session), and a signature (used to verify the token has not been tampered with). JWTs are widely used for authentication in REST APIs, OAuth 2.0 flows, and single sign-on systems.

In a typical JWT authentication flow, a user logs in with credentials, and the server generates a signed JWT containing user identity and permission claims. This token is returned to the client (usually stored in localStorage or an HTTP-only cookie) and sent with subsequent API requests in the Authorization header as a Bearer token. The server verifies the signature and reads the claims without needing to query a database, making JWT-based authentication stateless and scalable.

JWS (JSON Web Signature) and JWE (JSON Web Encryption) are two serialization formats defined by the JOSE specification. JWS tokens are signed but not encrypted, meaning anyone can read the payload by decoding the Base64URL, but they cannot modify it without invalidating the signature. JWE tokens are encrypted, so the payload contents are hidden from anyone without the decryption key. Most commonly used JWTs are JWS tokens. This decoder works with JWS tokens, which is the standard format for authentication tokens.

The JWT payload contains an "exp" (expiration time) claim as a Unix timestamp (seconds since January 1, 1970). This decoder automatically detects the exp claim, converts it to a human-readable date and time, and displays a warning if the token has expired. You can also check the "iat" (issued at) and "nbf" (not before) timestamps to understand the full validity window of the token.

Yes. Decoding a JWT only reveals the information already contained in the token — it does not verify the signature or grant any access. Since JWS payloads are merely Base64URL-encoded (not encrypted), anyone who possesses the token can decode it. This tool performs all decoding locally in your browser with no server communication, so your tokens are never exposed to third parties. However, you should never share your raw JWT tokens publicly, as they may contain sensitive claims.

The JWT specification (RFC 7519) defines seven registered claims: "iss" (issuer — who created the token), "sub" (subject — the user or entity the token represents), "aud" (audience — the intended recipient), "exp" (expiration time), "nbf" (not before — when the token becomes valid), "iat" (issued at — when the token was created), and "jti" (JWT ID — a unique identifier for the token). Applications typically add custom claims for roles, permissions, email, or other user-specific data.

JWTs support multiple signing algorithms specified in the header's "alg" field. HMAC algorithms (HS256, HS384, HS512) use a shared secret key for both signing and verification. RSA algorithms (RS256, RS384, RS512) use a private key to sign and a public key to verify, making them suitable for distributed systems. ECDSA algorithms (ES256, ES384, ES512) provide equivalent security to RSA with shorter key lengths. The "none" algorithm (unsigned) exists but should never be accepted in production systems due to security vulnerabilities.

The three dots in a JWT separate its three Base64URL-encoded components: header.payload.signature. The header specifies the token type and signing algorithm. The payload contains the claims (data). The signature is created by signing the encoded header and payload with a secret key or private key. This three-part structure allows any party to decode and read the header and payload, while only parties with the correct key can verify the signature or create new valid tokens.