JWT Builder

Select your signing algorithm (HMAC-SHA256 is the most common), then configure the payload claims in the visual editor. Standard claims include sub (subject identifier), iss (token issuer), aud (intended audience), exp (expiration time), iat (issued at), and nbf (not valid before). Add any custom claims your application needs. Enter your signing secret for HMAC algorithms or your private key for RSA and ECDSA. The tool generates the three-part JWT: Base64url-encoded header, Base64url-encoded payload, and cryptographic signature. The complete token is ready to copy and use in Authorization headers or API testing tools.

HMAC (HS256, HS384, HS512) uses a single shared secret for both signing and verification. It is the simplest option and works well when the same service creates and validates tokens. RSA (RS256, RS384, RS512) uses asymmetric key pairs where the private key signs and the public key verifies. This allows one service to issue tokens while others verify without knowing the private key. ECDSA (ES256, ES384, ES512) also uses asymmetric keys but with elliptic curve cryptography, producing significantly smaller signatures than RSA with equivalent security strength. Choose HMAC for single-service scenarios, RSA for distributed systems, and ECDSA when token size matters.

The exp claim is a Unix timestamp (seconds since January 1, 1970 UTC) representing when the token becomes invalid. The builder lets you set expiration as a duration from now (like 1 hour, 24 hours, or 7 days) and calculates the timestamp automatically. Short-lived tokens (15-60 minutes) are more secure because a stolen token has limited usefulness. Pair short access tokens with longer-lived refresh tokens to maintain sessions without frequent logins. The iat (issued at) claim records when the token was created, and nbf (not before) can delay when the token becomes valid. Always validate exp server-side and reject expired tokens even if the signature is valid.