{ sniptools }
Auth

JWT Generator

Create and sign JSON Web Tokens with custom claims

What is JWT?

JWT generation is the process of constructing a signed JSON Web Token from scratch by assembling a header, defining payload claims, and computing a cryptographic signature. While JWT decoding is about reading existing tokens, generation is about creating them — a task that typically lives on the server side of an authentication system but is invaluable to perform locally during development and testing.

In a production authentication flow, an identity provider (Auth0, Okta, Cognito, or your own auth server) generates JWTs after verifying user credentials. The token is then passed to client applications, which attach it to API requests. The receiving API validates the signature and reads the claims to authorize the request. During development, you often need tokens with specific claims, expiration times, or edge-case configurations that your identity provider cannot easily produce on demand.

A browser-based JWT generator fills this gap by letting you craft tokens with precise control over every field. You can create tokens that expire in 5 seconds to test refresh flows, tokens with unusual claim combinations to test validation edge cases, or tokens with specific roles to test authorization logic — all without configuring or deploying an auth server.

How it works

The generator constructs a JWT in three steps, mirroring the process described in RFC 7519. First, it builds the header JSON object containing the algorithm identifier ("alg": "HS256") and token type ("typ": "JWT"). Second, it constructs the payload JSON object from the claims you specify — standard claims like "sub", "iss", "exp", and "iat", plus any custom key-value pairs you add.

Both the header and payload are serialized to JSON strings, then encoded using Base64url encoding (replacing + with -, / with _, and stripping = padding). These two encoded strings are concatenated with a dot separator to form the signing input: base64url(header) + "." + base64url(payload).

The signing step uses the Web Crypto API to compute an HMAC-SHA256 (or SHA384/SHA512) digest of the signing input using your provided secret key. The secret is first imported as a CryptoKey, then the HMAC is computed over the signing input bytes. The resulting digest is Base64url-encoded and appended as the third segment, producing the complete JWT: header.payload.signature. The entire process runs in the browser — the secret key never leaves your device.

How to use this tool

  1. Select the signing algorithm from the dropdown. HS256 is the default and most common choice for development. HS384 and HS512 offer longer hash outputs if your API requires them.
  2. Enter your signing secret in the secret field. For testing purposes, any string works. For tokens that need to pass validation against a real service, use the same secret configured on that service.
  3. Define your payload claims using the claim editor. Add standard claims like "sub" (subject), "iss" (issuer), and "aud" (audience), then add any custom claims your API expects such as roles, permissions, or tenant identifiers.
  4. Set the expiration time using the "exp" claim. You can enter a specific Unix timestamp or use the relative time helper to set tokens that expire in minutes, hours, or days from now.
  5. Click Generate to produce the signed JWT. The complete token appears in the output area, ready to copy.
  6. Paste the generated token into your API client (Postman, curl, Thunder Client) as a Bearer token in the Authorization header, or use it directly in your application code for testing.

Examples

Creating a test token for a protected API endpoint

Set the subject to a test user ID, add a "role" claim with value "admin", and set expiration to 1 hour from now. Generate the token and use it as a Bearer token in Postman or curl to test that your API correctly grants admin access to protected resources.

Testing token expiration handling

Generate a token with "exp" set to 30 seconds from now. Use it in your application to trigger the token expiration flow and verify that your frontend correctly detects the expired token, attempts a refresh, and handles the case where no refresh token is available.

Simulating multi-tenant access

Create two tokens with different "tenant_id" claims but the same user subject. Use them to verify that your API correctly isolates data between tenants — a request with tenant A's token should not return tenant B's resources.

Testing missing or malformed claims

Generate tokens that deliberately omit required claims (no "sub", no "aud", expired "exp") to verify your API's validation logic returns appropriate error messages rather than crashing or granting access by default. This is an essential part of security testing.

About this tool

Build JWT tokens by specifying header algorithm, payload claims, and signing secret. Generate tokens for testing auth flows, API development, and debugging — all client-side using the Web Crypto API.

Common use cases

  • • Creating test tokens for API development without spinning up an auth server
  • • Generating JWTs with specific claims to test authorization logic and role-based access
  • • Building tokens with custom expiration times to test token refresh flows
  • • Prototyping authentication integrations before connecting to a real identity provider

Frequently asked questions

What signing algorithms does this tool support?
The JWT Generator supports HMAC-based algorithms (HS256, HS384, HS512) using the Web Crypto API. These are symmetric algorithms, meaning the same secret is used to sign and verify the token.
Can I use the generated tokens in production?
These tokens are intended for development and testing. While they are valid JWTs, production systems should generate tokens server-side with properly managed secrets and key rotation policies.
Does this tool send my signing secret anywhere?
No. All signing happens in your browser using the Web Crypto API. Your secret and generated tokens never leave your device.
What is the difference between HS256 and RS256?
HS256 (HMAC-SHA256) is a symmetric algorithm — the same secret key is used to both sign and verify the token. RS256 (RSA-SHA256) is asymmetric — a private key signs the token and a separate public key verifies it. HS256 is simpler and faster, suitable for single-server setups. RS256 is preferred when multiple services need to verify tokens independently without sharing a secret, which is why most identity providers use it. This tool supports HS256/384/512 since symmetric signing only requires a shared secret string.
How long should my JWT signing secret be?
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. Shorter secrets are technically accepted but weaken the cryptographic guarantee. Use a random string generated by a secure random number generator — not a human-memorable password. For development and testing with this tool, any string works, but production secrets should meet these minimum lengths.
What claims should I include when generating a test JWT?
At minimum, include "sub" (subject — usually a user ID), "iat" (issued at — current timestamp), and "exp" (expiration — typically 15-60 minutes from now for access tokens). Add "iss" (issuer) and "aud" (audience) if your API validates them. Then add whatever custom claims your application checks — roles, permissions, tenant ID, email, etc. The goal is to create a token that mirrors what your real identity provider would issue.