Free Online JWT (JSON Web Token) Decoder

Understanding JSON Web Tokens (JWT)

A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA. In modern web development, JWTs are commonly used for stateless user authentication and authorization. Once a user logs in, subsequent requests include the JWT, allowing the server to verify access permissions without querying a database on every request.

A JWT is represented as a single string divided into three distinct segments separated by periods (.):

1. Header: Details the token type and the signing algorithm used (such as HS256 or RS256).
2. Payload: Contains the claims, which are statements about the user entity (like user ID, roles, and issue/expiration times).
3. Signature: Used to verify that the sender is who they say they are and that the message has not been altered.

How it Works: The Base64Url Decoding Process

Because JWTs are sent over URL parameters, HTTP headers, or cookies, they must use a URL-safe text format. The three segments of a JWT are encoded using Base64Url encoding. Decoding a token involves separating these segments, translating them back to binary data, and parsing the underlying JSON string.

1. Splitting the Token

The algorithm splits the token string into an array of three strings based on the dot delimiter:

$$\text{JWT} = \text{Header} \mathbin{.} \text{Payload} \mathbin{.} \text{Signature}$$

2. Translating Base64Url to Standard Base64

Base64Url differs from standard Base64 because it replaces character elements that have special meanings in URLs (+ and /) with URL-safe replacements (- and _), and it strips trailing padding equals signs (=). To decode, the algorithm normalizes the string back to standard Base64:

• Replace all hyphens (-) with plus signs (+).
• Replace all underscores (_) with slashes (/).
• Calculate padding: If the string length is not a multiple of 4, append padding characters (=) until it matches (length modulo 4 equals 0):

$$\text{Padding Length} = (4 - (\text{Length} \pmod 4)) \pmod 4$$

3. Binary Decoding and JSON Parsing

The normalized standard Base64 string is decoded into binary data, translated into a UTF-8 character string, and parsed using JSON.parse() to return the header and payload objects.

Worked Examples: 3 Token Decoding Scenarios

Example 1: Basic Authentication Token

• Token (Header + Payload): eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
• Process:
• Header Base64Url: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 $\rightarrow$ Decoded: {"alg":"HS256","typ":"JWT"}
• Payload Base64Url: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ $\rightarrow$ Decoded: {"sub":"1234567890","name":"John Doe","iat":1516239022}
• Output: Decoded JSON data showing a signature type of HS256 and subject ID 1234567890.

Example 2: Token with Custom Claims and Expiration

• Token Payload: eyJVc2VySWQiOjQ1Niwicm9sZXMiOlsiYWRtaW4iLCJtZW1iZXIiXSwiZXhwIjoxODAwMDAwMDAwfQ
• Process: Normalize and decode Base64Url payload.
• Decoded Output:

{
"UserId": 456,
"roles": ["admin", "member"],
"exp": 1800000000
}

• Output: Expire timestamp translates to a future date, verifying token validity.

Example 3: Decoding a Token Header

• Token Header: eyJhbGciOiJSUzI1NiIsImtpZCI6IjEyM2FkYiJ9
• Decoded Output: {"alg":"RS256","kid":"123adb"}
• Output: Displays RSA algorithm usage and key ID.

Comparison: JWT vs. Alternatives

Edge Cases, Security Limitations, and Token Vulnerabilities

JWTs are powerful, but developers must understand critical security rules:

1. No Data Encryption: Standard JWTs are signed, not encrypted. Anyone who intercepts the token string can decode the Base64Url payload instantly using this tool and read the plain text claims. Never store sensitive credentials (like passwords or credit card numbers) in a JWT payload.
2. Signature Verification Limitation: Decoding a JWT is not the same as verifying a JWT. This visualizer decodes and displays the payload so you can read the claims. In an actual application, the server must verify the signature using the matching secret key before trusting any data inside the payload.
3. Algorithm "None" Vulnerability: Some poorly configured libraries allow verification using the "alg": "none" header parameter. An attacker can modify the header to none, strip the signature, and send the altered payload. Always disable support for the none algorithm in your backend libraries.
4. Clock Skew: Token expiration checks compare timestamps (exp and nbf). If the client machine's clock is out of sync with the authorization server, tokens may fail to validate.