JWT Generator

What is a JWT Generator?

A JWT Generator creates signed JSON Web Tokens that can be used for authentication, authorization, and secure data exchange between parties. This tool lets you craft a token with a custom header, payload, and HMAC secret — all entirely in your browser. No server-side processing, no data transmission, no logging.

Generated tokens follow the RFC 7519 standard and can be immediately verified by any compliant JWT library.

JWT Structure

A JWT has three dot-separated parts, each Base64URL-encoded:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   <- Header
.eyJzdWIiOiIxMjM0NTY3ODkwIn0            <- Payload
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_   <- Signature

Header

The header identifies the token type and the signing algorithm:

{
  "alg": "HS256",
  "typ": "JWT"
}

This tool supports three HMAC algorithms: HS256, HS384, and HS512. The alg field in the header updates automatically when you switch algorithms.

Payload

The payload carries claims — statements about the user or session:

{
  "sub": "user_id_123",
  "name": "Jane Doe",
  "roles": ["admin", "editor"],
  "iat": 1700000000,
  "exp": 1700086400
}

You can include any key-value pairs your application needs. Standard registered claims are recognized by most JWT libraries out of the box.

Signature

The signature binds the header and payload to your secret key:

HMAC-SHA256(base64url(header) + "." + base64url(payload), secret)

Without the correct secret, an attacker cannot forge a valid signature. This is what makes JWTs a trusted mechanism for stateless authentication.

Supported Algorithms

All three use a shared secret (symmetric cryptography). For asymmetric use cases (RSA, ECDSA), use RS256 or ES256 with your backend library.

Standard JWT Claims Reference

How to Use This JWT Generator

1. Select an algorithm — HS256 for broad compatibility, HS512 for maximum security.
2. Enter your secret key — this is the shared signing secret. Keep it confidential.
3. Edit the payload — add your custom claims (user ID, roles, expiration, etc.).
4. Click Generate Token — or edit any field for live auto-generation.
5. Copy the token — paste it into your application, API client, or test suite.

The header section is pre-filled with the correct alg and typ values and updates automatically when you switch algorithms.

Setting Token Expiration

Include an exp claim with a Unix timestamp in seconds:

{
  "sub": "user_123",
  "iat": 1700000000,
  "exp": 1700086400
}

To calculate the value: Math.floor(Date.now() / 1000) + seconds. Common durations:

Security Best Practices

Use strong secrets. A weak or short secret can be brute-forced. Secrets for HS256 should be at least 32 random bytes (256 bits). Generate with openssl rand -base64 32 or a secrets manager.

Never expose secrets client-side. JWTs signed with HMAC require the same secret for both signing and verification. Anyone who obtains the secret can forge tokens. Keep secrets in environment variables on your server.

Always set expiration. Tokens without an exp claim never expire and become a permanent risk if stolen. Use short-lived access tokens (15-60 minutes) and refresh tokens for longer sessions.

Validate all claims. After verifying the signature, your server must check exp, nbf, iss, and aud to ensure the token is still valid for the current request context.

Prefer asymmetric algorithms for multi-service architectures. If multiple services need to verify tokens, RS256 or ES256 lets you distribute the public key without exposing the signing secret.

Privacy

All signing in this tool uses the browser’s native Web Crypto API (crypto.subtle.sign). No data — secret, header, payload, or generated token — is ever sent to a server. The page runs entirely offline after loading.