JWT Generator
Generate signed JSON Web Tokens for testing integrations.
JWT Generator
Signed with a real HMAC (crypto.subtle) over the header and claims — supports HS256, HS384, and HS512 only. Asymmetric algorithms (RS256, ES256, etc.) aren't supported, since they'd require private-key input this tool doesn't collect.
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The JWT Generator builds a complete, signed JSON Web Token from a header, a set of claims you define, and a shared secret — the tool for creating a fresh token from scratch, as opposed to the JWT Inspector (which decodes an existing token to see what's inside) or the JWT Claims Editor (which takes an existing token and modifies it). You choose an HMAC signing algorithm, set standard claims like expiration and issuer, add whatever custom claims your application needs, and get back a ready-to-use, correctly-encoded and correctly-signed token.
- Building a token by hand — base64url-encoding a header and payload, then computing the correct signature — is mechanical but genuinely easy to get subtly wrong: a missed padding character, an incorrectly-serialized JSON payload, or a signature computed over the wrong encoded string all produce a token that looks plausible but fails validation the moment a real library checks it. This tool handles that encoding and signing correctly by construction, which is exactly why it's useful for testing: you can generate a token with precisely the claims and expiration you want to test against a backend's validation logic, without hand-assembling the token structure yourself.
- This is a testing and prototyping tool, not a production token-issuance service — the secret or key you use here should be a throwaway test value, never your application's real signing secret, since anything typed into a browser tool should be treated as no longer secret.
How It Works
- You select an HMAC signing algorithm (HS256, HS384, or HS512, each using a shared secret) and provide that secret.
- You define the payload claims: standard claims like sub (subject), exp (expiration), iat (issued at), and iss (issuer), plus any custom claims your application needs.
- The header and payload are each serialized to JSON and base64url-encoded.
- The signature is computed over the concatenated encoded header and payload using the chosen algorithm and key, then base64url-encoded itself.
- The three encoded parts are joined with periods to produce the final token: header.payload.signature.
Usage
- Choose an HMAC signing algorithm (HS256, HS384, or HS512) and provide the shared secret — use a throwaway test value, not a real production secret.
- Define the claims you want in the payload: standard claims like expiration and subject, plus any custom claims your test scenario needs.
- Generate the token and copy the resulting three-part string.
- Use the JWT Inspector to double-check the generated token decodes to exactly the claims you intended before using it in a test.
- Use the token in your test request, or hand it to a teammate who needs a token with specific claims for their own testing.
Examples
- Generating an HS256 token with a 5-minute expiration to test that a client correctly handles token expiry mid-session.
- Generating a token with a custom role claim set to admin to test that role-based authorization logic correctly grants access.
- Generating an HS512 token to test that a service configured for the stronger HMAC variant accepts it correctly.
- Generating a token with a deliberately malformed or missing required claim to confirm a backend's validation logic actually checks for it rather than assuming it's always present.
Real-World Use Cases
- Generating a test token with a specific set of claims to verify a backend correctly authorizes (or rejects) requests based on those claims.
- Creating a deliberately expired token to test whether an application correctly rejects it rather than silently accepting a stale session.
- Prototyping the claim structure for a new authentication flow before writing the actual token-issuance code in your backend language.
- Generating tokens signed with a known test secret for use in local development or automated integration tests, without needing a running auth server.
Best Practices
- Always use a throwaway test secret or key pair, never a real production signing secret, when generating tokens in a browser tool — treat anything entered here as no longer confidential.
- Set a short, realistic expiration when generating test tokens for expiry-handling tests, rather than a far-future date that won't actually exercise the expiration logic.
- Verify a generated token with the JWT Inspector before using it in a test, to catch a claim-definition mistake before it costs you time debugging the wrong layer.
- Match the algorithm you generate with to the algorithm your target system actually expects — a token signed with the wrong algorithm will be rejected regardless of whether the claims themselves are correct.
Common Mistakes
- Using a real, production-relevant secret or key when generating a test token in a browser — once typed into any tool, it should be treated as compromised and rotated.
- Forgetting to set an expiration claim at all, producing a token that's valid indefinitely — useful occasionally for isolated testing, but a poor default for anything resembling a real session.
- Assuming a generated token will work against a system expecting a different signing algorithm — HS256, HS384, and HS512 tokens are not interchangeable; the verifying side must be configured for the exact algorithm used to sign. This tool signs HMAC algorithms only — it cannot generate RS256/ES256 or other asymmetric-key tokens.
- Putting sensitive data directly in the payload claims for a test token — JWT payloads are only encoded, not encrypted, so anything in there is trivially readable by anyone who has the token.
Limitations
- This tool generates tokens locally in your browser for testing and prototyping — it is not a substitute for a real authentication server's token-issuance logic, which typically also handles user lookup, credential verification, and refresh-token issuance.
- It signs HMAC algorithms only — HS256, HS384, and HS512 — via a real crypto.subtle HMAC signature. Asymmetric algorithms (RS256, ES256, and similar) aren't supported, since verifying or signing those needs private-key material this browser tool doesn't collect.
- Secrets and keys entered here exist only in local browser memory during the session and are not persisted — you'll need to re-enter them if you reload the page.
Technical Reference Guide
- JSON Web Tokens are defined by RFC 7519; the signing mechanism (JWS) is defined by RFC 7515.
- Standard registered claim names — iss, sub, aud, exp, nbf, iat, jti — are catalogued in RFC 7519 Section 4.1, and using them correctly (rather than inventing custom equivalents) improves interoperability with any library that inspects them.
- HMAC-based signing (HS256, HS384, HS512) uses the mechanism defined in RFC 2104, computed here via the browser's native crypto.subtle. RSA-based signing (RS256 and variants) follows RFC 8017 (PKCS #1), but this tool doesn't generate RS256/ES256 tokens, since that needs private-key material a browser tool doesn't collect.
FAQ
Is it safe to generate a token with my real production secret in this tool?
No — treat any secret or key entered into a browser tool as no longer confidential. Use a throwaway test value, and if a real secret is ever accidentally entered anywhere, rotate it.
What's the difference between this tool and the JWT Claims Editor?
This tool builds a brand-new token from claims you define from scratch. The JWT Claims Editor starts from an existing token and lets you modify its claims, then re-encodes it — useful for testing how a system handles a tampered or altered version of a real token.
Which signing algorithm should I use?
This tool signs HMAC algorithms only: HS256, HS384, or HS512, in increasing order of digest strength. HS256 is the most common default; use HS384/HS512 if your target system specifically expects a stronger variant. It cannot generate RS256/ES256 or other asymmetric-key tokens.
Can I generate a token without an expiration claim?
Yes, but it's rarely a good idea outside of narrow testing scenarios — a token with no exp claim remains valid indefinitely, which doesn't reflect how a real session token should behave.
Will a token generated here work with any backend?
Only if the backend is configured with the matching signing algorithm and secret/key — a token is only as valid as the verifying system's ability to check its signature against the same credentials used to create it.
Can I put sensitive data in the payload?
You can, but you shouldn't — JWT payloads are base64url-encoded, not encrypted, so anyone who has the token can decode and read every claim in it.
Part of this Developer Hub
This utility is part of our comprehensive Authentication & Tokens Lab topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the API & Web Engineering Lab workshop for complementary engineering workflows.
View all API & Web Engineering Lab tools