JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties. A JWT consists of three parts: Header, Payload, and Signature, joined by dots. It is widely used for API authentication, single sign-on (SSO), and information exchange.
Header: Contains the token type and signing algorithm, e.g., {"alg":"HS256","typ":"JWT"}. The alg field specifies the signing algorithm, and the typ field specifies the token type (usually JWT).
Payload: Contains claims — statements about an entity (typically the user) and additional data. Standard claims include: sub (subject), iss (issuer), aud (audience), exp (expiration time), iat (issued at), nbf (not before), etc.
Signature: Signs the Base64Url-encoded Header and Payload using the algorithm specified in the Header, ensuring the token has not been tampered with. The signature formula is: HMACSHA256(base64Url(header) + "." + base64Url(payload), secret)
Step 1: Configure the Header. Enter the JWT header information, which typically includes the algorithm type (alg) and token type (typ). The default is HS256, but you can switch to HS384 or HS512 for higher security.
Step 2: Fill in the Payload. Enter JSON-formatted data in the Payload area. Claims in the Payload are divided into three categories: registered claims (e.g., exp, iat, sub), public claims (custom but non-conflicting), and private claims (used internally by the application). It is recommended to include at least sub (user ID) and exp (expiration time).
Step 3: Set the Secret Key. The Secret Key is the core of HMAC signing and must be strong (256 bits or more recommended). You can click the "Random Secret" button to auto-generate a strong key, or enter one manually.
Step 4: Generate the Token. Click the "Generate JWT Token" button. The tool uses the Web Crypto API to compute the signature in the browser. The generated token is displayed in "Header.Payload.Signature" format, with each part color-coded for easy identification.
Step 5: Verify the Signature. After generating the token, click "Verify Signature" to recompute the signature and compare it with the token's signature, confirming the token's integrity.
• API Authentication: After user login, the server issues a JWT, which the client carries in subsequent requests for authentication, replacing traditional Session mechanisms.
• Single Sign-On (SSO): JWTs can carry user information across different domains, enabling a single-login, multi-access experience.
• Information Exchange: JWTs enable secure transmission of information between untrusted parties, with the signature ensuring the information has not been tampered with.
• Microservices Authentication: In a microservices architecture, JWTs serve as authentication credentials for inter-service communication, avoiding the overhead of verifying user identity on every request.
• Keep the Secret Key secure. Do not hardcode it in code; use environment variables or key management services.
• Data in the Payload is Base64-encoded and can be decoded by anyone. Do not store passwords or other sensitive information in the Payload.
• Always set a reasonable exp (expiration time) to avoid the security risks of long-lived tokens.
• Use HTTPS to transmit JWTs, preventing tokens from being intercepted during transmission.
• Rotate Secret Keys regularly to reduce the impact of key compromise.
These are all HMAC signing algorithms. The difference lies in the hash algorithm used: HS256 uses SHA-256 (recommended as default), HS384 uses SHA-384, and HS512 uses SHA-512. Larger numbers provide higher security but also require more computational overhead. For general web applications, HS256 is sufficiently secure.
This tool runs entirely in the browser. All data (including the Secret Key) is processed locally and never uploaded to any server. However, note that the JWT Payload is Base64-encoded and can be decoded by anyone. Do not store sensitive information (such as passwords) in the Payload.
Use the exp (expiration time) claim in the Payload to set the validity period. The exp value is a Unix timestamp (in seconds) representing the expiration point. For example, setting exp to current time + 3600 means the token expires in 1 hour. It is recommended to also set iat (issued at).
The Secret Key is the core of HMAC signing and must: 1) Be sufficiently long (at least 32 bytes / 256 bits recommended); 2) Contain a random combination of uppercase, lowercase, numbers, and special characters; 3) Be kept confidential; 4) Be rotated regularly.
Common reasons include: 1) Secret Key mismatch (the key used for verification differs from the one used for generation); 2) Wrong algorithm selected (the alg in the Header does not match the actual signing algorithm); 3) Token tampering (the Signature part was modified). Ensure the same Secret Key and algorithm are used for verification.
You can put any JSON-formatted data in the Payload, but it is recommended to follow JWT standard claim conventions. Common standard claims include: sub (subject/user ID), iss (issuer), aud (audience), exp (expiration time), iat (issued at), nbf (not before), jti (unique identifier), etc. Custom claims should avoid using reserved names.
Session authentication requires the server to store session data and query it on every request. JWT encodes authentication information in the token itself; the server only needs to verify the signature to confirm token validity, without storing sessions. This is more suitable for distributed and microservices architectures. However, once issued, a JWT cannot be actively revoked; shorter expiration times are used to control this.
A common approach is the "dual token" strategy: use a short-lived Access Token (e.g., 15 minutes) and a long-lived Refresh Token. When the Access Token expires, the client uses the Refresh Token to request a new Access Token from the server. The Refresh Token is typically stored in an HttpOnly Cookie for better security.