JWT Generator & Mock Token Builder
Generate local JWTs for testing, customize claims, simulate expiry, and create intentionally invalid signatures safely in your browser.
Your secrets and keys stay private. All signing happens locally using the browser's Web Crypto API. No server uploads. No token logging. No remote signing. Safe for auth debugging, QA, and local testing workflows.
Header
Symmetric — shared secret, both sides need the same key
Payload (JSON)
JWT time claims (exp, iat, nbf) are Unix seconds, not milliseconds. Applying a preset overwrites the time fields in the payload above.
Signing secret
For testing only — never use production secrets in a browser tool.
All signing happens locally using the browser's native Web Crypto API. Secrets, private keys, and generated tokens are never uploaded to CodeAva servers, transmitted over the network, or stored between sessions. This makes the tool safe for testing with real-looking key material that must not leave your development environment.
What JWTs are and why local test generation matters
A JSON Web Token (JWT) is a compact, URL-safe credential format used across most modern authentication and authorization systems. It consists of three Base64URL-encoded sections — header, payload, and signature — joined by dots. The header declares the signing algorithm. The payload carries claims: structured assertions about the subject, issuer, audience, permissions, and validity window. The signature proves the token was created by a party that holds the signing key.
During development and QA, you often need tokens that do not exist in your test environment yet: a token with a specific tenant_id, a token with an expired exp, a token with elevated permissions for a role your staging environment does not expose, or an intentionally tampered token to verify that your middleware rejects it correctly. Generating these by hand — or by running throwaway scripts — is slow and inconsistent.
Local browser-based generation matters when handling secrets and private keys. Any tool that accepts a signing key and makes a server request is a risk. This tool uses the browser's SubtleCrypto API to sign tokens entirely in memory. No key material is transmitted. No token is logged. The generation environment is your browser tab.
How do you generate a JWT for testing purposes?
To generate a JWT for testing, you need three things: a header that declares the signing algorithm, a payload containing the claims your application expects, and a signature produced from a secret or private key. For QA workflows, it is important to generate at least three variants: a valid token that should pass, an expired token that should be rejected with a 401, and a tampered token that should be rejected with a signature verification failure. Testing only the happy path leaves significant security gaps.
JWT signing algorithm comparison
Choosing the right algorithm depends on your architecture, your key distribution model, and your interoperability requirements. Here is a practical comparison of the four algorithms this tool supports:
| Algorithm | Type | Best use case | Practical note |
|---|---|---|---|
| HS256 | Symmetric | Internal service-to-service tokens where both ends share the secret | Simple to implement. Both issuer and verifier must hold the same secret — not suitable when the verifying party is a third party or a public client. |
| HS512 | Symmetric | Same as HS256 with a larger HMAC digest | Produces a 512-bit signature instead of 256-bit. Uses the same shared-secret model. Choose HS512 if your security policy requires a larger digest; otherwise HS256 is sufficient. |
| RS256 | Asymmetric (RSA) | OIDC flows, public APIs, and any scenario where the verifier is a third party | Private key signs; public key verifies. The public key can be published via JWKS. Standard choice for OIDC-compliant identity providers. Larger key and signature size than ES256. |
| ES256 | Asymmetric (ECDSA P-256) | Modern APIs, mobile-first systems, and environments where signature size matters | Smaller keys and signatures than RS256 with equivalent security strength. Growing adoption in modern auth stacks. PKCS#8 PEM format required for browser-side key import. |
Verifying a CodeAva-generated token in Node.js
Tokens generated by this tool are standard JWTs — they can be verified by any compliant JWT library. Here is an example using the jsonwebtoken package in Node.js:
const jwt = require('jsonwebtoken');
// For HS256 / HS512 — same secret used to sign in CodeAva
const secret = 'your-super-secret-key-for-testing-only';
try {
const payload = jwt.verify(token, secret, { algorithms: ['HS256'] });
console.log(payload.sub); // "user_12345"
console.log(payload.role); // "developer"
} catch (err) {
// TokenExpiredError, JsonWebTokenError, NotBeforeError
console.error(err.message);
}
// For RS256 — use the public key that matches the private key
// used to sign in CodeAva
const publicKey = fs.readFileSync('public.pem');
const payload = jwt.verify(token, publicKey, { algorithms: ['RS256'] });The algorithm in the verification call must match the alg header in the token. If the algorithm does not match — or if the key does not correspond — verification will throw a JsonWebTokenError. This is exactly the rejection path the Signature Saboteur feature is designed to trigger and test.
For production systems, signing keys should be managed by dedicated secret-management infrastructure — AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, or equivalent. The CodeAva tool is for safe local generation and testing workflows, not production key operations.
What this tool helps with
Good uses
- Testing auth middleware with specific claim shapesgenerate tokens with the exact role, scope, tenant_id, or permissions structure your middleware expects, without waiting for a test user to be provisioned.
- Simulating expired tokensuse the 'Expired (−24 h)' preset to generate a token whose exp is in the past. Verify that your middleware returns 401 Unauthorized and that your frontend handles the expiry response correctly.
- Testing future nbf (not-before) rejectionapply the 'Future nbf' preset to generate a token that is not yet valid. Confirm your backend rejects it before the nbf timestamp.
- Mocking tenant or role claims for multi-tenant systemsuse the quick-add controls to inject tenant_id, role, or permissions claims and generate tokens for different tenant contexts without modifying your identity provider.
- Generating batches of test tokens for load testinguse bulk generation to produce up to 50 tokens with incrementing sub, user_id, or tenant_id values. Download as .txt for use in k6, Artillery, or Postman environments.
- Verifying backend rejection of tampered tokensuse the Signature Saboteur to produce an intentionally invalid token — tampered signature, swapped payload, or modified header — and confirm your auth layer rejects it with the correct error.
Limitations to know
- Production token issuancethis tool is for local development and QA. Production JWT issuance should be handled by a server-side auth system with proper key storage, rotation, and audit logging.
- RS256 and ES256 without a correctly formatted PKCS#8 PEM keythe browser's Web Crypto API requires PKCS#8 format for private key import. PKCS#1 (traditional) RSA keys and SEC1 EC keys will fail to import. Convert with openssl pkcs8 -topk8 -nocrypt if needed.
- Verifying existing tokensthis tool signs new tokens — it does not verify signatures on existing ones. Use the JWT Decoder for payload inspection, or use your server-side library for authoritative signature verification.
- Storing real credentials in generated tokensmock tokens are for testing token-handling logic, not for carrying real user credentials or sensitive production data. Use realistic-looking but entirely fictional claim values.
How to generate a JWT for testing
- 1
Choose a signing algorithm
Select HS256 or HS512 for symmetric testing (shared secret required) or RS256 / ES256 for asymmetric workflows (PKCS#8 PEM private key required). The algorithm selector drives the key input below it.
- 2
Edit the payload claims
The JSON editor comes pre-populated with common claims. Edit directly or use the quick-add buttons on the sidebar. The editor validates JSON in real time and prevents generation if the JSON is malformed.
- 3
Apply an expiry preset
Click a time preset — 5 min, 1 hour, 24 hours, Expired, or Future nbf — to set correct Unix second timestamps. The time preview shows UTC and local time for each claim so you can verify the values before signing.
- 4
Provide the secret or private key
For HS algorithms, enter a test secret or click the refresh icon to generate a random 32-byte hex secret. For RS256 and ES256, paste a PKCS#8 PEM private key. Nothing is transmitted.
- 5
Generate, copy, and test rejection paths
Click Generate JWT. Copy the token or Bearer string. Inspect the decoded header and payload in the preview panels. Open the Signature Saboteur to create a tampered variant and test that your backend rejects it correctly.
Common issues and how to fix them
Token expires immediately or appears expired before I use it
JWT exp, iat, and nbf values are Unix timestamps in seconds, not milliseconds. If you copy a JavaScript Date.now() value directly, it will be roughly 1000x too large, producing a timestamp far in the future or — if the value overflowed — appearing already expired. Use the time presets or enter Math.floor(Date.now() / 1000) manually.
RS256 or ES256 signing fails with a key import error
The browser's Web Crypto API requires PKCS#8 format. Traditional RSA private keys (BEGIN RSA PRIVATE KEY) and SEC1 EC keys (BEGIN EC PRIVATE KEY) will fail. Convert with: openssl pkcs8 -topk8 -nocrypt -in key.pem -out key-pkcs8.pem. Then paste the converted key.
Payload JSON editor shows an error but the JSON looks correct
Common causes: trailing commas (not valid in JSON, only in JavaScript), single quotes instead of double quotes, unescaped backslashes in string values, or a comment left in the JSON. Use the JSON Formatter to validate and fix the payload.
Signature verification in my server fails for a HS256 token
The most common cause is a mismatch between the signing secret used here and the secret configured in your verification library. They must be byte-for-byte identical. Also confirm you are specifying algorithms: ['HS256'] explicitly in your verify call — algorithm pinning prevents algorithm confusion attacks.
The tampered token is being accepted by my backend
Your middleware may not be verifying the signature at all, or it may be using the 'alg: none' bypass path. Check that your JWT library has alg: none disabled and that algorithm pinning is explicit. A correctly configured library must reject any token with a tampered signature.
Bulk generation is slow for RS256 or ES256
Asymmetric signing using Web Crypto is significantly more computationally expensive than HMAC. Generating 50 RS256 tokens will take noticeably longer than 50 HS256 tokens. For bulk QA fixtures with asymmetric algorithms, consider generating a smaller batch or switching to HS256 for local test token generation.