JWT Generator

What Is a JWT Generator?

A JWT generator is a tool that creates signed JSON Web Tokens from a header, payload, and secret key. While a JWT decoder lets you inspect existing tokens, a JWT generator lets you craft new ones — which is essential during development, testing, and debugging of authentication systems. This tool complements our JWT Decoder by handling the creation side of the JWT lifecycle.

Unlike server-side JWT libraries, this generator runs entirely in your browser. It uses the Web Crypto API (crypto.subtle) to perform HMAC signing with SHA-256, SHA-384, or SHA-512. No data is sent to any server, making it safe to use with test secrets and payloads.

How JWT Signing Works

JWT signing is a three-step process that ensures the token’s integrity and authenticity:

1. Encode the header: The header JSON object is serialized to a UTF-8 string and then Base64URL-encoded. The header specifies the algorithm (alg) and token type (typ).
2. Encode the payload: The payload JSON object containing the claims is similarly serialized and Base64URL-encoded.
3. Sign: The encoded header and encoded payload are concatenated with a dot separator to form the signing input: base64url(header).base64url(payload). This string is then signed using the specified HMAC algorithm and the secret key. The resulting signature is Base64URL-encoded and appended after another dot.

The final token has the format: header.payload.signature, where each part is Base64URL-encoded. This format is compact, URL-safe, and can be transmitted in HTTP headers, URL parameters, or POST body fields.

Supported Algorithms

HS256 (HMAC-SHA256)

HS256 is the most commonly used symmetric JWT signing algorithm. It uses SHA-256 to create a 256-bit HMAC signature. HS256 is the default algorithm in most JWT libraries and is suitable for the majority of use cases where the same party both signs and verifies the token. It offers a good balance of security and performance.

HS384 (HMAC-SHA384)

HS384 uses SHA-384 to produce a 384-bit signature. It provides a higher security margin than HS256 at the cost of a slightly larger signature. HS384 is less commonly used in practice but is available for applications that require a stronger hash function.

HS512 (HMAC-SHA512)

HS512 uses SHA-512 to generate a 512-bit signature, providing the highest security level among the HMAC algorithms. The signature is longer, but the computational cost difference is negligible on modern hardware. HS512 is recommended when maximum security is a priority and token size is not a concern.

Symmetric vs. Asymmetric Algorithms

All three algorithms supported by this tool (HS256, HS384, HS512) are symmetric — the same secret key is used for both signing and verification. This is appropriate when the signing party and the verifying party are the same service, or when the secret can be securely shared. For scenarios where the signer and verifier are different entities (such as microservice architectures), asymmetric algorithms like RS256 (RSA) or ES256 (ECDSA) are preferred because they use a private key for signing and a public key for verification.

Understanding JWT Claims

The payload of a JWT contains claims — key-value pairs that carry information about the token’s subject and metadata. The JWT specification (RFC 7519) defines several registered claims:

• iss (Issuer) — Identifies the principal that issued the JWT. Typically a URL like https://auth.example.com. Servers should validate this claim to ensure the token was issued by a trusted authority.
• sub (Subject) — Identifies the principal that is the subject of the JWT. Usually the user ID (e.g., user_12345 or a UUID). This is the most important claim for identifying the authenticated user.
• aud (Audience) — Identifies the recipients the JWT is intended for. Can be a single string or an array. API servers should reject tokens where the audience does not match their own identifier.
• exp (Expiration Time) — A Unix timestamp after which the token must not be accepted. This is the primary mechanism for limiting a token’s lifetime. Common values range from 5 minutes (for access tokens) to 30 days (for refresh tokens).
• iat (Issued At) — A Unix timestamp indicating when the token was created. Useful for determining the token’s age and for time-based policies.
• nbf (Not Before) — A Unix timestamp before which the token must not be accepted. This allows you to create tokens that become valid in the future.

The preset buttons in this tool make it easy to add these standard claims with sensible default values. The exp button sets expiration to one hour from now, while iat and nbf are set to the current time.

Web Crypto API for JWT Signing

This tool uses the Web Crypto API (window.crypto.subtle) to perform HMAC signing. The Web Crypto API is a W3C standard available in all modern browsers (Chrome, Firefox, Safari, Edge) and provides hardware-accelerated cryptographic operations. The signing process involves two steps:

1. crypto.subtle.importKey() — Imports the secret string as a CryptoKey object with the HMAC algorithm and the appropriate hash function (SHA-256, SHA-384, or SHA-512).
2. crypto.subtle.sign() — Signs the encoded header and payload string using the imported key. The result is an ArrayBuffer containing the raw signature bytes, which are then Base64URL-encoded.

Because the Web Crypto API runs natively in the browser, no external cryptography libraries are needed. The key material never leaves the browser’s memory, and the entire operation is performed synchronously within the browser process.

Common Use Cases for JWT Generation

Testing Authentication Flows

During development, you often need to create test JWTs to verify that your API correctly validates tokens, checks expiration, and extracts claims. This tool lets you quickly generate tokens with specific payloads and expiration times without writing code or setting up a test authentication server.

Debugging API Authorization

When an API returns a 401 or 403 error, generating a fresh token with known claims and verifying it against your server’s configuration helps isolate whether the problem is in the token itself, the signing key, or the server’s validation logic.

Learning and Teaching JWT Concepts

The visual breakdown of header, payload, and signature makes this tool excellent for learning how JWTs work. You can modify the payload, see how the token changes, and verify the decoded output to understand the relationship between the three parts.

Prototyping Webhook Signatures

Some webhook systems use JWT-style HMAC signatures for request verification. This tool can generate the appropriate HMAC signature for testing webhook endpoints without deploying the sending service.

Security Best Practices

• Never use production secrets in browser tools. While this tool does not transmit your secret, browser environments are susceptible to extensions, console access, and memory inspection. Use test secrets only.
• Use strong secrets. For HMAC algorithms, the secret should be at least as long as the hash output (32 bytes for HS256, 48 bytes for HS384, 64 bytes for HS512). Use a cryptographically random string, not a simple password.
• Set short expiration times. Access tokens should typically expire within 5 to 15 minutes. Use refresh tokens for longer sessions.
• Validate all registered claims on the server. Check iss, aud, exp, nbf, and iat during token verification to prevent misuse.
• Prefer asymmetric algorithms in production. For microservice architectures where multiple services verify tokens, use RS256 or ES256 so that the signing key stays with the auth server.

Frequently Asked Questions

Is it safe to use this tool with my secret key?

All signing happens in your browser using the Web Crypto API. Your secret key is never sent to any server. However, you should still use test secrets rather than production keys, as browser environments can be inspected through developer tools and extensions.

Can I generate RSA or ECDSA tokens?

This tool currently supports HMAC algorithms (HS256, HS384, HS512) only. RSA and ECDSA signing require key pair generation and management, which adds complexity. For asymmetric tokens, use a server-side JWT library like jsonwebtoken (Node.js), PyJWT (Python), or jjwt (Java).

How do I verify the generated token?

You can paste the generated token into our JWT Decoder to inspect its contents. For cryptographic verification, use a JWT library in your backend language with the same secret key and algorithm.

Why does the token change when I modify the payload?

The signature is computed from the encoded header and payload. Any change to either part produces a completely different signature. This is by design — it prevents tampering. Even changing a single character in the payload will result in a completely different token.

What is Base64URL encoding?

Base64URL is a variant of Base64 encoding that is safe for use in URLs and filenames. It replaces + with -, / with _, and removes trailing = padding. This ensures the token can be transmitted in URL parameters and HTTP headers without encoding issues.