What Is a JWT Generator?

A JWT generator creates signed JSON Web Tokens for use in authentication and authorization flows. JWTs are compact, URL-safe strings consisting of a header, payload, and signature — all Base64URL-encoded and joined by dots. This tool generates signed JWTs entirely in your browser using the jose library and the Web Crypto API. Nothing is sent to any server.

How to Generate a JWT — Step by Step

1. Choose an algorithm: HS256, HS384, or HS512.
2. Enter a secret key — or click 🎲 to generate a cryptographically random 32-byte hex secret.
3. Fill in standard claims: sub (user ID), iss (issuer), aud (audience).
4. Pick an expiry duration: 15 minutes, 1 hour, 7 days, 30 days, or no expiry.
5. Add any custom claims as key-value pairs using the + Add button.
6. The signed JWT appears live on the right — color-coded header (red), payload (purple), signature (blue).
7. Click Copy JWT to copy the full token to your clipboard.

HS256 vs HS384 vs HS512 — Which Should You Use?

• HS256 — HMAC with SHA-256. The most widely supported algorithm. Use this for most applications where you control both the issuer and verifier and share a single secret key.
• HS384 — HMAC with SHA-384. Larger internal hash state. Marginally slower, negligibly more secure than HS256 in practice. Rarely needed.
• HS512 — HMAC with SHA-512. Maximum HMAC key size. Use when your security policy requires SHA-512, or when generating tokens for hardware security modules (HSMs).

All three are symmetric — the same key is used to sign and verify. If you need asymmetric signing (e.g., share a public key with third-party verifiers), use RS256 or ES256 in your server-side JWT library.

How to Choose a Secure Secret Key

For HS256, your secret should be at least 256 bits (32 bytes) of high-entropy random data. Click the 🎲 button to generate a cryptographically secure 32-byte hex secret using crypto.getRandomValues(). Avoid human-readable passwords as HMAC secrets — they have far less entropy than random bytes. Never reuse secrets across environments (dev, staging, production) and rotate them regularly.

Standard JWT Claims Explained

• sub — Subject: the entity the token represents (typically a user ID like user_1234).
• iss — Issuer: identifies who generated the token (typically your app domain, e.g. api.example.com).
• aud — Audience: the intended recipient(s). Used to prevent a token issued for one service from being used by another.
• exp — Expiry: Unix timestamp after which the token is invalid. Set automatically based on the expiry option you pick.
• iat — Issued at: Unix timestamp when the token was created. Always set to the current time.

Custom Claims Use Cases

Custom claims carry application-specific data that your API needs to authorise requests without querying the database on every call. Common examples:

• role: "admin" — permission level for role-based access control (RBAC).
• orgId: "org_456" — multi-tenant identifier to scope data access.
• plan: "pro" — subscription tier for feature gating.
• scope: "read:users write:reports" — OAuth 2.0-style permission scope string.

Related Tools

• JWT Decoder — Paste any JWT to inspect its header, payload claims, and expiry status.
• Hash Generator — Generate SHA-256 and other hashes from strings or secrets.
• Password Generator — Generate high-entropy random secrets for signing keys and API tokens.