Ttooleras
🎫

JWT Generator

Developer Utilities

Create signed JSON Web Tokens (JWT) with custom claims — HS256, RS256, ES256. Free, private — all processing in your browser.

Advertisement

The JWT Generator creates signed JSON Web Tokens for testing, development, and custom auth implementations. Build the header and payload with a visual claims editor (set sub, iss, aud, exp, custom claims), choose the signing algorithm (HS256 for symmetric, RS256/ES256/EdDSA for asymmetric), provide the signing key, and get a complete JWT ready to paste into Authorization headers, cookies, or API tests. Opposite of our JWT Decoder — the decoder parses existing JWTs; this tool creates new ones.

Use the generator to: test your auth middleware (create JWTs with specific claims to test edge cases), mock an identity provider during development (generate fake IDP tokens for integration testing), create expired tokens to test rejection logic, craft tokens with custom claims for permission testing, or study JWT structure by experimenting with different algorithms and payloads. All signing happens in your browser using Web Crypto API — your keys never upload anywhere.

JWT Generator — key features

Visual claims editor

Set standard claims (iss, sub, aud, exp, etc.) with a structured form. Add custom claims with key-value pairs.

Auto-compute exp and iat

Click to set iat to now and exp to now + 1 hour (or custom duration). No manual timestamp math.

All standard algorithms

HS256/384/512, RS256/384/512, ES256/384, EdDSA. Match any API requirement.

Generate key pairs

For asymmetric algorithms, generate RSA or EC key pairs in browser. Use same session or export for production.

Test expired tokens

Set exp to a past timestamp to create intentionally-expired JWTs for testing your rejection logic.

Import existing JWT to edit

Paste an existing JWT and edit the claims, re-sign with your key. Useful for debugging.

Base64URL output

All three parts (header.payload.signature) properly Base64URL-encoded. Ready to paste into Authorization header.

100% client-side

Signing keys and tokens stay in your browser. Safe for production keys and sensitive payloads.

How to use the JWT Generator

  1. 1

    Edit the header

    Choose algorithm (HS256 default). Optionally set kid (key ID) if using multiple keys. typ auto-set to JWT.

  2. 2

    Edit the payload

    Set standard claims (sub, iss, aud, exp) with the form. Add custom claims as key-value pairs (role, permissions, tenant, etc.).

  3. 3

    Set timestamps

    Click Now for iat to set to current time. Set exp to now + duration (1h, 24h, 7d, etc.). Timestamps are Unix seconds.

  4. 4

    Provide signing key

    For HS256: a shared secret (32+ bytes, text or hex). For RS256/ES256: private key in PEM format (paste or generate in browser).

  5. 5

    Click Generate

    Tool signs the JWT with your key and algorithm. Output is the complete JWT ready to use.

  6. 6

    Verify by decoding

    Optionally paste the output into [JWT Decoder](https://tooleras.com/tools/jwt-decoder) to verify the structure is correct.

Common use cases for the JWT Generator

Development and testing

  • →Test auth middleware: Create JWTs with specific claims (admin role, specific tenant, etc.) to test access control code paths.
  • →Create expired tokens for testing: Set exp to past timestamp. Verify your app correctly rejects expired tokens with 401.
  • →Integration testing: Generate tokens with known test user IDs for E2E tests. Avoid hitting real auth provider in tests.
  • →Mock identity provider: When developing against an OIDC provider, generate equivalent mock JWTs with same structure for offline development.

API development

  • →Custom auth implementation: Generate JWTs on your backend for session tokens. This tool helps prototype and debug token generation.
  • →Refresh token generation: Create refresh tokens with longer expiration and refresh-specific claims.
  • →Service-to-service auth: Microservices authenticate each other with short-lived JWTs. Generate test tokens.
  • →Signed URLs with JWT: Time-limited download URLs encoded as JWTs. Create and test.

Learning and documentation

  • →Understand JWT structure: Generate JWTs with different algorithms and claims. Decode to see structure. Visual learning.
  • →Compare algorithms: Same claims, different algorithms (HS256 vs RS256 vs ES256). Compare signature sizes and formats.
  • →Demonstrate security issues: Generate alg: none tokens to demonstrate the vulnerability in security training.
  • →Build JWT-related tutorials: Create example tokens with known payloads for documentation.

Debugging

  • →Reproduce auth bugs: Generate tokens matching a bug report to reproduce the issue locally.
  • →Test edge cases: Unusual claim combinations, very large payloads, unusual characters. Test how your code handles them.
  • →Craft tokens for SQL injection tests: Security testing: generate tokens with malicious-looking claims to test sanitization.
  • →Test rate limiting: Generate many distinct tokens to simulate multiple users.

JWT Generator — examples

Basic HS256 JWT

Simple token with sub and exp.

Input
Header: {alg: HS256, typ: JWT}
Payload: {sub: user_42, exp: 1714525200}
Key: test-secret-key
Output
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQyIiwiZXhwIjoxNzE0NTI1MjAwfQ.5mhB...

Full standard claims

With all registered claims.

Input
Payload: {iss: https://auth.example.com, sub: user_42, aud: api.example.com, exp: now+1h, iat: now, jti: unique_id}
Output
Valid JWT with all standard claims
Verifiable by service expecting api.example.com as aud

Admin role token

Token with custom role claim.

Input
Payload: {sub: admin_user, role: admin, permissions: [read, write, delete]}
Output
Token carrying admin role and permissions.
Your authz code can read these claims to grant access.

RS256 with asymmetric key

Token signed with RSA private key.

Input
Algorithm: RS256
Private key: RSA 2048-bit (PEM)
Payload: standard claims
Output
JWT with longer signature section (RSA signatures are larger than HMAC).
Verifiable by anyone with public key.

ES256 for modern APIs

Elliptic Curve signature.

Input
Algorithm: ES256
Private key: P-256 (shorter than RSA)
Payload: standard
Output
Compact JWT with small signature.
Recommended for new deployments.

Expired token for testing

exp in the past.

Input
exp: 1000000 (in 1970)
Output
Token is valid but exp indicates expiration in the past.
Your verifier should reject this with an expired token error.

Technical details

JSON Web Token (JWT, RFC 7519) is a compact, URL-safe token consisting of three Base64URL-encoded parts separated by dots: header, payload, and signature.

Header structure:

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

- alg: signing algorithm (HS256, RS256, ES256, EdDSA, none)
- typ: always "JWT"
- kid: (optional) key identifier for multi-key rotation

Payload (claims) structure:

Claims are key-value pairs. Some are registered claims (RFC 7519):

- iss (issuer): who issued the token
- sub (subject): who the token is about (user ID)
- aud (audience): who should accept this token
- exp (expiration): Unix timestamp after which invalid
- nbf (not before): Unix timestamp; invalid before this
- iat (issued at): Unix timestamp when created
- jti (JWT ID): unique identifier

Any additional custom claims are allowed:

``json
{
"sub": "user_42",
"iss": "https://auth.tooleras.com",
"exp": 1714525200,
"iat": 1714521600,
"role": "admin",
"tenant": "tooleras"
}
``

Signing algorithms:

| Algorithm | Type | Key requirements | Use case |
|---|---|---|---|
| HS256 | HMAC-SHA256 | Shared secret (32+ bytes) | Single-service systems |
| HS384 | HMAC-SHA384 | Shared secret (48+ bytes) | Same, higher security |
| HS512 | HMAC-SHA512 | Shared secret (64+ bytes) | Same, highest security |
| RS256 | RSA + SHA-256 | RSA private/public key pair (2048-bit+) | Multi-service, public verification |
| RS384/RS512 | Like RS256 with larger hash | RSA 3072+ for RS512 | Higher security variants |
| ES256 | ECDSA P-256 + SHA-256 | EC key pair (256-bit curve) | Modern default, smaller signatures |
| ES384 | ECDSA P-384 + SHA-384 | EC key pair (384-bit curve) | Higher security EC |
| EdDSA | Ed25519 | Ed25519 key pair | Modern best, fastest, smallest |
| none | No signature | None | AVOID - security risk |

Signing process:

1. Encode header as JSON, then Base64URL (no padding).
2. Encode payload as JSON, then Base64URL.
3. Concatenate: header_b64.payload_b64.
4. Sign with chosen algorithm and key.
5. Append signature: header_b64.payload_b64.signature_b64.

Symmetric vs asymmetric:

- **Symmetric (HS*): Same key signs and verifies. Simpler, faster. Use when single service both issues and verifies.
- Asymmetric (RS*, ES*, EdDSA)**: Private key signs, public key verifies. Public key can be shared widely. Use when verification happens in multiple services or clients.

Security considerations:

- Never accept alg: none — critical security vulnerability.
- Verify alg matches expected — do not let attackers switch algorithms.
- Validate exp — reject expired tokens.
- Validate aud — reject tokens not for your service.
- Keep symmetric keys secret; public keys can be distributed.

Common problems and solutions

⚠Do not use alg: none in production

alg: none means no signature. Anyone can craft valid tokens with any claims. Historical CVE (CVE-2015-9235). Always reject alg: none in verifiers. Only use for security demonstration.

⚠HS256 key too short

RFC 2104 recommends key length equal to or greater than hash output (32 bytes for HS256). Short keys are internally padded but reduce security. Generate 32+ byte random keys from CSPRNG, not password-derived.

⚠Accidentally shipping test tokens

Tokens created here are real JWTs. If you share them, anyone with the signing key can decode or forge. Treat test keys and tokens carefully — do not hardcode in production.

⚠Wrong algorithm for use case

HS256 requires sharing the signing key with all verifiers. If multiple services need to verify, use RS256/ES256 (private signs, public verifies). Do not use HS256 across organizations.

⚠Missing required claims

Many systems require specific claims (aud, iss). Token without them may be rejected. Check receiving systems requirements before generating.

⚠JWT payload too large

JWTs travel in HTTP headers (often 8 KB limit). Do not stuff entire user profile. Keep payload small — user ID + basic claims only. Look up details from a cache on each request.

⚠Unencrypted claims (not same as unsigned)

JWT payload is Base64-encoded, not encrypted. Anyone can decode and read. Do NOT put passwords, SSNs, credit cards in JWT payload. Use JWE (JSON Web Encryption) if you need encrypted tokens.

⚠Keys committed to git

Private keys in git history are a catastrophic leak. Once leaked, rotate immediately. Use environment variables, secret managers. Git-ignore key files.

JWT Generator — comparisons and alternatives

JWT Generator vs Decoder: Generator creates new JWTs; decoder parses existing ones. Use together during development: generate test tokens, decode to verify structure. Our JWT Decoder handles the reverse direction.

JWT vs Session cookies: JWT is self-contained (all claims in token). Session cookies reference server-side session storage. JWT is stateless (easier for microservices); sessions are easier to revoke (just delete server-side).

HS256 vs RS256 vs ES256: HS256 uses symmetric HMAC — simpler, faster, shared key. RS256 uses RSA — asymmetric, public verification, larger signatures. ES256 uses elliptic curve — asymmetric but compact (modern default). Choose based on who needs to verify.

JWT vs PASETO: PASETO (Platform-Agnostic Security Tokens) is a modern alternative designed to fix JWT pitfalls (no alg: none, one algorithm per version). Less adoption; consider for new projects where JWT is not required.

JWT vs Opaque Tokens: Opaque tokens are random strings that reference server-side data. Smaller, easier to revoke, but require database lookup per request. JWTs are self-contained, larger, harder to revoke. OAuth 2.0 supports both as access tokens.

JWT (JWS) vs JWE: JWT (JWS) is signed — payload readable by anyone. JWE is encrypted — payload hidden from clients. Use JWS for authentication (default); JWE when payload contains sensitive data that must not be exposed.

Frequently asked questions about the JWT Generator

▶What is a JWT (JSON Web Token)?

A compact, URL-safe token format (RFC 7519) for transmitting claims between parties. Consists of three Base64URL-encoded parts: header (algorithm), payload (claims), and signature (cryptographic proof). Widely used in OAuth 2.0, OpenID Connect, and API authentication.

▶Is this JWT Generator safe to use with real keys?

Yes. Generation happens entirely in your browser using Web Crypto API. Your signing keys (HMAC secrets or RSA/EC private keys) never upload anywhere. Safe for production keys. Verify with DevTools Network tab — no outbound key transmission.

▶Which algorithm should I use?

ES256 is the modern best choice — fast, small signatures, asymmetric. HS256 for single-service systems where signing and verifying key can be shared. RS256 for public verification with large existing ecosystem. EdDSA (Ed25519) is even newer and better but less universally supported. Avoid MD5, none, and deprecated algorithms.

▶How do I generate a signing key?

For HS256: random 32+ byte string from CSPRNG (not a password). Our Password Generator can create one. For RS256/ES256: use our RSA Key Generator or OpenSSL CLI to create a key pair.

▶What claims should I include?

Minimum: sub (user ID), exp (expiration). Strongly recommended: iss (issuer), aud (audience), iat (issued at), jti (unique ID). Custom claims for your application: role, permissions, tenant, feature flags. Keep payload small — stored data should be minimal.

▶How long should the expiration be?

Access tokens: 15 minutes to 1 hour. Short enough that leakage is manageable. Refresh tokens: 7 days to 30 days. Longer-lived but stored securely. ID tokens: a few hours. For testing, any duration works; for production, balance security vs user experience.

▶Can I generate expired tokens?

Yes. Set exp to a past Unix timestamp. Useful for testing your auth middleware correctly rejects expired tokens with 401 Unauthorized.

▶What is kid and when should I use it?

kid (key ID) identifies which key signed the token. Used when rotating keys: old tokens have old kid, new tokens have new kid. Receivers look up the correct key from a JWKS (JSON Web Key Set) endpoint. Essential for key rotation without invalidating existing tokens.

▶How is the signature calculated?

Sign = algorithm(base64url(header) + . + base64url(payload), key). For HS256: HMAC-SHA256. For RS256: RSA signature over SHA-256 hash. For ES256: ECDSA signature. The signature proves the token was signed with the private key and has not been modified.

▶Why is my generated JWT rejected by the API?

Common causes: (1) Wrong algorithm — API expects HS256, you used RS256. (2) Wrong key — signing and verifying keys do not match. (3) Missing required claims — API requires specific iss, aud, exp. (4) Expired — exp is in the past. (5) Invalid signature — key mismatch or corrupted token.

Additional resources

Advertisement

Related tools

All Developer Utilities
🔄

Base64 Encoder/Decoder

Encode and decode Base64 strings, files, and images instantly

🔒

Bcrypt Hash Generator

Hash passwords with bcrypt and verify existing hashes — configurable rounds

🔐

Hash Generator

Generate MD5, SHA-1, SHA-256, SHA-512 hashes for text and files

🔏

HMAC Generator

Generate HMAC signatures (SHA-256, SHA-512) for API auth and webhook verification

🎫

JWT Decoder

Decode and inspect JSON Web Token (JWT) headers, payloads, and signatures

🔑

Password Generator

Generate strong, cryptographically secure random passwords

Learn more

How to Decode a JWT: A Practical Debugging Guide (with the Base64URL Gotcha Nobody Warns You About)

17 min read

UUID v4 vs v7: The Default Has Quietly Changed

22 min read

MD5, SHA-1, SHA-256: Three Kinds of Hashing Everyone Confuses

24 min read

Explore more tools

200+ free tools that run in your browser.

Browse all tools →