How to use the JWT generator
Start by selecting your signing algorithm. HS256 is the default and most commonly used HMAC algorithm. HS384 and HS512 use longer hash outputs if your security policy requires them. Next, enter or generate a secret key—click the "Random" button to create a cryptographically random 32-character key, or type your own. This key is what the recipient uses to verify the token signature.
Edit the payload JSON to include your custom claims. The generator automatically adds "iat" (issued at) and "exp" (expiration) timestamps based on the current time and your chosen expiry duration in seconds. You can also set optional standard claims: "iss" (issuer) identifies who created the token, and "aud" (audience) specifies the intended recipient. Add any custom key-value pairs your application needs directly in the JSON editor.
The generated token appears in the right panel, color-coded by segment: red for the header, purple for the payload, and cyan for the signature. Click "Copy" to copy the full token to your clipboard. The decoded header and payload are shown below for verification. Use this token for API testing, development environments, or to understand JWT structure before implementing token generation in your server code.
Understanding JWT structure
A JSON Web Token consists of three parts separated by dots. The header contains metadata about the token: the signing algorithm (like HS256) and the token type (JWT). The payload contains claims—statements about the user and additional data. Claims are categorized as registered (standard names like sub, iss, exp), public (defined in the IANA JWT Claims Registry), and private (custom claims agreed between parties).
The signature is created by taking the encoded header, encoded payload, a secret key, and the algorithm specified in the header, then applying the cryptographic function. For HMAC algorithms, this means HMAC-SHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret). The signature ensures the token hasn't been altered—any change to the header or payload invalidates the signature.
It's important to understand that JWT payloads are encoded, not encrypted. Anyone can decode the header and payload using Base64URL decoding. Never store sensitive data like passwords or credit card numbers in JWT claims. The signature provides integrity (tamper detection) and authenticity (proof of origin), but not confidentiality. If you need encrypted tokens, look into JWE (JSON Web Encryption) instead.
JWT best practices for developers
Keep tokens short-lived. Access tokens should typically expire in 15 minutes to 1 hour. Use refresh tokens (stored securely, often in HTTP-only cookies) to obtain new access tokens without re-authentication. This limits the damage window if a token is compromised and reduces the need for complex token revocation infrastructure.
Always validate tokens on the server side. Check the signature, verify the expiration time, confirm the issuer and audience match expected values, and validate any custom claims your application relies on. Never trust a JWT without full verification. Client-side validation is insufficient because the secret key should never be exposed to the browser.
Store secrets securely using environment variables or a secrets manager—never hardcode them in source code or commit them to version control. Rotate secrets periodically and have a plan for key rotation that doesn't immediately invalidate all existing tokens. Consider using asymmetric algorithms (RS256, ES256) for systems where the token creator and verifier are different services, since only the private key can sign while any service with the public key can verify.
Frequently Asked Questions
What is a JSON Web Token (JWT)?
A JWT is a compact, URL-safe token format used for securely transmitting information between parties. It consists of three Base64URL-encoded parts separated by dots: a header (algorithm and type), a payload (claims like user ID, expiration, issuer), and a signature that verifies the token hasn't been tampered with. JWTs are widely used for authentication, authorization, and information exchange in APIs.
Is this generator safe for production tokens?
This tool generates structurally valid JWTs for development, testing, and learning. The signature is computed in-browser using a simplified HMAC approach. For production systems, use server-side libraries like jsonwebtoken (Node.js), PyJWT (Python), or java-jwt (Java) that implement full cryptographic signing with proper key management.
What are the common JWT claims?
Standard claims include: 'sub' (subject — usually user ID), 'iss' (issuer — who created the token), 'aud' (audience — intended recipient), 'exp' (expiration time as Unix timestamp), 'iat' (issued at time), 'nbf' (not before — token not valid before this time), and 'jti' (JWT ID — unique identifier). You can also add any custom claims your application needs.
What's the difference between HS256, HS384, and HS512?
These are HMAC-based algorithms that use SHA-256, SHA-384, and SHA-512 hash functions respectively. HS256 is the most common and sufficient for most use cases. HS384 and HS512 provide longer signatures and theoretically higher collision resistance, but HS256 is already considered secure. The choice depends on your security requirements and compatibility needs.
How long should a JWT secret key be?
For HS256, the secret should be at least 256 bits (32 bytes). For HS384, at least 384 bits (48 bytes). For HS512, at least 512 bits (64 bytes). Using a secret shorter than the algorithm's hash output weakens the signature. Use a cryptographically random generator — never use simple words or short strings as secrets in production.
Why do JWTs expire?
Expiration limits the window during which a stolen token can be misused. Short-lived tokens (15 minutes to 1 hour) are recommended for access tokens. Refresh tokens can have longer lifetimes. Without expiration, a compromised token grants permanent access until the secret key is rotated, which affects all tokens.
Privacy and methodology
This tool runs entirely in your browser. The JWT is assembled using standard Base64URL encoding for the header and payload. The signature is computed locally using a simplified HMAC approach suitable for development and educational use. No data, secrets, or tokens are sent to any server. For production token generation, use established server-side libraries with proper cryptographic implementations.