How to Decode a JWT Safely (Without Sending It to a Server)

A JSON Web Token (JWT) appears as a mysterious string, but it is actually three encoded sections linked together by dots. Anyone possessing the token can view its contents, as no secret key is required. This is intentional: JWTs are meant for verification, not concealment. Understanding this is crucial when handling them. The three components of a JWT are the header (eyJhbGciOiJIUzI1NiJ9), the payload (eyJzdWIiOiIxMjMiLCJleHAiOjE3MDAwMDAwMDB9), and the signature (binary signature, Base64URL-encoded).

When split by dots, the first two parts can be decoded and converted to JSON, revealing metadata about the token and its claims. The header contains information like the signing algorithm (e.g., HS256) and sometimes the token type or key ID. The payload holds the claims, which can be predefined (such as iss, sub, aud, exp, nbf, and iat) or custom-defined by the application.

The signature is a cryptographic proof that the token hasn't been tampered with and was issued by someone with access to the key. To decode a JWT manually, split the token at the two dots to obtain the three segments, then decode the first segment by swapping hyphens for pluses, underscores for forward slashes, adding padding, and executing Base64 decoding.

Parse the result as JSON to obtain the header. Repeat the process for the second segment to read the payload. The signature should remain untouched as it is binary data, not JSON. While decoding a JWT can be done in a browser console with a single line of code (e.g., JSON.parse(atob(token.split('. ')[1].replace(/-/g, '+').replace(/_/g, '/)))), it is essential to remember that decoding does not verify the token's authenticity.

Decoding only reveals the token's contents, whereas verification ensures its integrity and authenticity. This is typically done on a server with the appropriate key. Verification also includes checking that the expiration time (exp) is in the future, that the issuer (iss) and audience (aud) match what your server expects, and that the algorithm (alg) is one you authorize.

Do not blindly trust the alg header, as this can leave your system vulnerable to certain attacks. Never paste live tokens into random websites, as they often send this information to their backend or load scripts that could log the token. Instead, use a decoder that runs entirely in your browser, ensuring nothing is sent to external servers. If you must decode a production token, revoke or rotate it immediately to maintain security.