JWT Generator

You’re building a JWT authentication system and need test tokens — one with exp set to 5 minutes from now, another with a specific role claim, a third with aud set to your staging API. Writing the Base64 encoding and HMAC signing by hand in code takes 20 lines and a crypto library import. You need a visual builder that lets you set claims and get a signed token instantly.

Why This Generator (Not the JWT Decoder)

PureDevTools has a JWT Decoder for inspecting existing tokens and a JWT Debugger for detailed claim analysis. This tool builds and signs new JWT tokens — set the algorithm (HS256/384/512), configure standard claims (iss, sub, aud, exp, iat, nbf, jti), add custom claims, provide a secret, and get a signed token. Everything runs in your browser; no tokens are sent to any server.

What Is a JWT?

A JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting claims between parties as a compact, URL-safe string. A JWT is composed of three Base64URL-encoded parts separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← Header
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ   ← Payload
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c   ← Signature

This tool lets you construct a JWT from scratch: define the header algorithm, fill in standard and custom payload claims, provide your signing secret, and receive a signed token instantly — all without sending anything to a server.

How JWT Generation Works

Generating a JWT involves three steps:

1. Encode the header — serialize the header JSON ({"alg":"HS256","typ":"JWT"}) and Base64URL-encode it.
2. Encode the payload — serialize the claims JSON and Base64URL-encode it.
3. Sign — compute HMAC-SHA256(base64url(header) + "." + base64url(payload), secret) and Base64URL-encode the result.

The final token is header.payload.signature. This tool performs all three steps in your browser using the Web Crypto API.

Supported Algorithms

This tool supports the three HMAC-based JWT algorithms defined in RFC 7518:

HMAC algorithms use a symmetric secret — the same key signs and verifies the token. They are the simplest option for single-service authentication. For multi-service or public-key scenarios, RS256 (RSA) or ES256 (ECDSA) are preferred, though they require key pairs not supported here.

Standard JWT Claims

RFC 7519 defines seven registered claim names. This tool provides dedicated fields for all of them:

All timestamp fields accept either an ISO 8601 datetime (e.g., 2024-12-31T23:59:59) or a Unix timestamp in seconds (e.g., 1735689599). Leaving a field blank omits it from the token.

Custom Claims

Beyond the standard registered claims, you can add any number of custom (private) claims to the payload. Common examples:

{
  "role": "admin",
  "permissions": ["read", "write", "delete"],
  "org_id": 42,
  "email_verified": true
}

This tool supports four value types for custom claims:

• String — any text value: "admin", "john@example.com"
• Number — integer or decimal: 42, 3.14
• Boolean — true or false
• JSON — any JSON value: objects {"key":"val"}, arrays [1,2,3], or primitives

Signing Secret

The signing secret is the key used to compute the HMAC signature. Keep it private — anyone who knows the secret can forge arbitrary tokens.

Best practices for secrets:

• Use at least 256 bits of entropy for HS256 (32+ random bytes)
• Generate secrets with a cryptographically secure random number generator
• Never hardcode secrets in client-side code or public repositories
• Rotate secrets periodically and after any suspected compromise

The tool accepts secrets either as:

• UTF-8 — a plain text string (most common for development)
• Base64 — a Base64-encoded byte sequence (common for production keys)

JWT Security Considerations

The payload is not secret. Base64URL encoding is not encryption — anyone who holds the JWT token can decode and read the payload. Never put sensitive data (passwords, private keys, PII) in a JWT payload.

Validate expiry on the server. The exp claim must be checked server-side on every request. Client-side expiry checks are for UX only, not security.

Prevent token replay. Use the jti claim with server-side tracking for sensitive operations where a token must only be used once.

Avoid alg: none. Some JWT libraries historically accepted "alg":"none" with no signature. Always validate the alg field and reject tokens with unexpected algorithms on the server.

Common Use Cases for JWT Generation

Testing and development — generate tokens with custom claims to test API endpoints without standing up an authentication server.

Microservices — create short-lived tokens to authenticate inter-service calls in local development or staging environments.

API documentation — generate example tokens to include in API docs or Postman collections.

Security research — test how your application handles various claim configurations, expired tokens, or unusual payload structures.

Learning JWT — the live preview makes it easy to understand exactly how claim values map to the encoded token.

Privacy and Security

This JWT Generator runs entirely in your browser using the Web Crypto API. Your secret and payload claims are never sent to any server, stored, or logged. You can safely use this tool in air-gapped or offline environments once the page has loaded.

Frequently Asked Questions

What is the difference between HS256, HS384, and HS512? All three are HMAC-based algorithms using different SHA hash functions. HS256 uses SHA-256 (256-bit output), HS384 uses SHA-384, and HS512 uses SHA-512. A longer hash provides marginally more collision resistance but has no practical security advantage for JWTs — HS256 is sufficient for most use cases.

Can I use this tool to generate production JWTs? For development and testing, yes. For production, use a server-side JWT library (jsonwebtoken, PyJWT, jose, etc.) so your secret is never exposed in client-side code. This tool is ideal for generating test tokens, debugging, and learning.

Why is my token expiring immediately? Make sure your exp timestamp is in the future. Timestamps must be Unix seconds (not milliseconds). For example, 1735689599 is December 31, 2024 at 23:59:59 UTC.

How do I verify a JWT I generated here? Use the JWT Decoder tool on this site to paste the token and verify its HMAC signature with the same secret.

What is the typ field in the header? The typ (type) parameter identifies the media type of the complete JWT. For standard JWTs, the value is "JWT". Some systems use custom values for application-specific token types.