JWT Generator Free Online Tool 2026

Last updated March 22, 2026

Generating a Basic HS256 Token

Create a simple JWT signed with HMAC-SHA256. Configure the generator with these settings:

Algorithm: HS256
Secret Key: my-super-secret-key-for-development

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

Payload:
{
  "sub": "user_12345",
  "name": "Alice Johnson",
  "iat": 1700000000,
  "exp": 1700086400
}

Generated token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMzQ1IiwibmFtZSI6IkFsaWNlIEpvaG5zb24iLCJpYXQiOjE3MDAwMDAwMDAsImV4cCI6MTcwMDA4NjQwMH0.abc123signature

The token is valid for 24 hours (86400 seconds) from the issued-at time.

Generating a Token with Role Claims

For testing role-based access control, generate tokens with different role values. Admin token payload:

{
  "sub": "user_001",
  "email": "admin@example.com",
  "role": "admin",
  "permissions": ["read", "write", "delete", "manage_users"],
  "iat": 1700000000,
  "exp": 1700086400
}

Editor token payload:

{
  "sub": "user_002",
  "email": "editor@example.com",
  "role": "editor",
  "permissions": ["read", "write"],
  "iat": 1700000000,
  "exp": 1700086400
}

Viewer token payload:

{
  "sub": "user_003",
  "email": "viewer@example.com",
  "role": "viewer",
  "permissions": ["read"],
  "iat": 1700000000,
  "exp": 1700086400
}

Use each token to test that your API correctly allows or denies access based on the role claim.

Generating an Already-Expired Token

To test your application's expired token handling, set the exp claim to a past timestamp:

{
  "sub": "user_12345",
  "iat": 1600000000,
  "exp": 1600003600
}

Both iat and exp are in the past (September 2020). When your application receives this token, it should return a 401 Unauthorized response with an appropriate error message like "Token has expired". Use this to verify your token validation middleware handles expiration correctly.

Generating a Long-Lived Development Token

For local development, create a token that won't expire for a year:

{
  "sub": "dev_user",
  "name": "Developer",
  "role": "admin",
  "env": "development",
  "iat": 1700000000,
  "exp": 1731536000
}

The exp value is set approximately one year in the future. This avoids the frustration of tokens expiring mid-development session. Never use long-lived tokens in production environments.

Generating a Token with Custom Application Claims

Real applications often add custom claims for tenant isolation, feature flags, or subscription data:

{
  "sub": "user_789",
  "iss": "https://auth.yourapp.com",
  "aud": "https://api.yourapp.com",
  "iat": 1700000000,
  "exp": 1700086400,
  "tenantId": "tenant_abc123",
  "plan": "enterprise",
  "features": ["analytics", "export", "api_access", "sso"],
  "maxSeats": 100,
  "region": "us-east-1"
}

Generate this token and use it to test that your API correctly reads and enforces the tenantId, plan, and features claims.

Generating an RS256 Token (Asymmetric)

For applications using RSA signing, provide a private key in PEM format:

Algorithm: RS256

Private Key (PEM):
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA2a2rwplBQLF29amygykEMmYz0+Kcj3bKBp29...
-----END RSA PRIVATE KEY-----

Payload:
{
  "sub": "service_account_1",
  "iss": "https://auth.yourapp.com",
  "aud": "https://api.yourapp.com",
  "iat": 1700000000,
  "exp": 1700003600,
  "scope": "read:users write:posts"
}

The generated RS256 token can be verified using the corresponding public key. This is the standard approach for microservices where the token issuer and verifier are separate services.

Generating a Token for API Testing

When testing an API endpoint that requires authentication, generate a token matching your application's expected claims structure:

{
  "sub": "test_user_001",
  "email": "testuser@example.com",
  "emailVerified": true,
  "role": "user",
  "iat": 1700000000,
  "exp": 1700086400,
  "jti": "unique-token-id-abc123"
}

Use this token in your API test requests:

curl -X GET https://api.yourapp.com/users/profile \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..."

Generating a Token with nbf (Not Before) Claim

The nbf claim makes a token invalid before a specific time — useful for testing scheduled access:

{
  "sub": "user_456",
  "iat": 1700000000,
  "nbf": 1700003600,
  "exp": 1700090000
}

This token is issued now but becomes valid only 1 hour later (nbf = iat + 3600). Your application should reject this token with a 401 error until the not-before time is reached. Use this to test that your JWT validation checks the nbf claim correctly.

Understanding the Three Token Parts

The generator displays the token with its three parts color-coded. For the token above:

• Red part (header): eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 — decodes to {"alg":"HS256","typ":"JWT"}
• Purple part (payload): eyJzdWIiOiJ1c2VyXzEyMzQ1Ii4uLn0 — decodes to your claims object
• Blue part (signature): SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c — HMAC-SHA256 of header.payload

The header and payload are base64url-encoded, not encrypted. Anyone who has the token can read the claims. Never store sensitive data like passwords or credit card numbers in JWT claims.

Generating Tokens for Multi-Tenant Testing

Test that your application correctly isolates data between tenants by generating tokens for different tenants:

// Tenant A token
{
  "sub": "user_001",
  "tenantId": "tenant_alpha",
  "role": "admin",
  "exp": 1700086400
}

// Tenant B token
{
  "sub": "user_002",
  "tenantId": "tenant_beta",
  "role": "admin",
  "exp": 1700086400
}

Use Tenant A's token to attempt accessing Tenant B's resources. Your API should return 403 Forbidden, confirming that tenant isolation is working correctly.