JWT Generator

Use HMAC (HS256, HS384, HS512) when the same application both creates and verifies tokens — typical for monolithic applications where your authentication server and API servers are controlled by the same team. HMAC uses a shared secret meaning both signing and verification use the same key. This is simpler to implement but the secret must be securely shared between all components that verify tokens. Use RSA (RS256) or ECDSA (ES256) when you want asymmetric signing: the authentication server signs tokens with its private key, and any service with the public key can verify tokens. This is the recommended approach for microservices architectures where multiple services need to verify tokens but should not be able to sign new tokens. Use RSA/ECDSA when integrating with external identity providers (Auth0, Okta) who publish public keys for token verification. Our tool supports both approaches.

JWT expiration (exp claim) is a security critical decision balancing security and user experience. Short-lived tokens (15-60 minutes) better security due to shorter attack window if compromised but inconvenience users with frequent re-authentication. Long-lived tokens (24 hours or more) better user experience but risk from compromised tokens remains active longer. Best practices: access tokens should be short-lived (15 minutes to 1 hour); use refresh tokens (long-lived, stored securely, like 7-30 days) to obtain new access tokens without user interaction; set expiration for sensitive operations (account deletion, payment processing) to under 15 minutes; always check exp claim in your token validation middleware; and use refresh token rotation to mitigate token theft. Our generator supports relative time expressions (1h for one hour, 7d for seven days) for easy expiration time generation.

Essential claims include: exp (expiration time) — required for security, prevents infinite-lived tokens; iat (issued at) — useful for determining token age and implementing expiration policies; sub (subject) — identifies the token owner, typically the user ID from your database; iss (issuer) — identifies which server issued the token, useful in multi-server setups; aud (audience) — identifies which services should accept this token, prevents token reuse across services; and jti (JWT ID) — unique identifier for the token, enables token revocation lists and replay attack prevention. Common custom claims include: roles/permissions for authorization decisions, tenant ID for multi-tenant applications, and session ID linking the token to a server-side session for forced logout. Avoid storing sensitive data (passwords, PII) in JWTs even though they are signed, because signed data is easily decoded by anyone possessing the token.

Use our generator to create test tokens for various scenarios: valid token with correct claims and signature — your application should accept this; expired token (set exp to a past timestamp) — your application should reject with 401 Unauthorized; wrong algorithm (generate with HS256 but your app expects RS256) — your application should reject; tampered payload (decode a valid token, modify a claim, re-encode without re-signing) — your application should reject due to signature mismatch; missing required claims (omit exp or sub) — your application should reject if these are required; wrong audience (set aud to a different service) — your application should reject; and token signed with wrong secret — your application should reject. This systematic testing ensures your JWT validation middleware correctly handles all edge cases and security scenarios.

Our tool is designed for development and testing purposes only. For production JWT generation, always use established libraries in your backend code (jsonwebtoken for Node.js, PyJWT for Python, java-jwt for Go jwt for Go, etc.) running on your secure servers. The security concern with online tools is that secrets entered in the browser could potentially be intercepted or logged. Our tool processes everything client-side in JavaScript without sending data to any server, but for production secrets you should never enter them in any web-based tool. Use our generator for: creating test tokens for development environments, learning JWT structure and claims, prototyping authentication flows, and generating example tokens for documentation. For production, generate tokens in your backend code where secrets are stored in environment variables or secret management systems.