JWT Generator
Generate and sign HS256 JSON Web Tokens entirely in your browser. Your secret never leaves the page.
- Runs in your browser
- No upload, no tracking
- Free forever
Only HS256 is supported. The secret never leaves your browser.
How it works
A JWT generator builds a signed JSON Web Token from a header, a payload of claims and a secret — base64url-encoding each part and appending an HS256 HMAC signature so the token can later be verified as untampered. This tool signs with the browser's native Web Crypto API and runs entirely client-side, so your secret never leaves the page. It is built by JusDB, a managed database operations team, for the auth and integration testing that surrounds every application.
- 1
Edit the header
The header defaults to { alg: "HS256", typ: "JWT" }. Only HS256 signing is supported, so leave alg as HS256.
- 2
Set the payload claims
Edit the payload JSON — the default seeds sub, name, iat and a one-hour exp. Add any standard or custom claims you need.
- 3
Provide a secret
Enter your HS256 shared secret. The token is signed and recomputed live; invalid JSON shows an error instead.
- 4
Copy the signed token
Copy the colour-coded token, or copy the decoded header and payload to confirm the result. Reset restores the defaults.
Frequently asked questions
- What signing algorithm is supported?
- HS256 (HMAC with SHA-256). It uses a shared secret to sign the token via the browser's native crypto.subtle.sign() API — no external libraries.
- Is my secret key safe?
- Yes. The secret is used locally in your browser to compute the HMAC signature. It is never sent to JusDB or any server. Close the tab to clear it from memory.
- Can I see the decoded token?
- Yes. The tool automatically decodes and displays the header and payload of the generated token below the token output.
- What are iat and exp in the payload?
- iat (issued at) is the Unix timestamp when the token was created. exp (expiration) is the Unix timestamp after which the token is no longer valid. Both are standard JWT claims.
- Does the token regenerate as I edit?
- Yes. The signed token is recomputed live whenever you change the header, payload or secret. If the header or payload is not valid JSON, an error is shown instead of a token.
- Are tokens from this tool safe to use in production?
- These tokens are real, valid HS256 JWTs, but they are intended for testing and development. Use a long, random secret, and never paste a production signing secret into any browser tool you do not control.
Generating JWTs for local testing the right way
When you are building an API or a protected route, you often need a valid token in hand before the real login flow exists. Minting one here lets you exercise authorization middleware, role checks and token-expiry handling without standing up an identity provider first. The trick is to treat the generated token as a disposable test fixture, not as anything your production system should ever trust.
Shaping the payload: claims, exp and custom data
Start with the registered claims your code actually reads. A sub identifies the principal, iat records when the token was issued, and exp sets the expiry as a Unix timestamp. Both iat and exp are seconds since the epoch, not milliseconds — a common off-by-1000 mistake that makes a token look permanently expired or valid for millennia.
Custom claims are just extra fields: drop in { "role": "admin", "tenant": "acme" } to test branch logic, then regenerate with a viewer role to confirm the deny path. Editing the payload here lets you reproduce edge cases — a missing claim, a malformed scope, an already-expired token — far faster than walking through a UI login each time. Keep exp short (minutes, not days) even in dev, so a leaked test token stops working quickly and your code never quietly grows a dependency on long-lived tokens.
HS256 vs RS256: symmetric secret or asymmetric keypair
HS256 signs and verifies with a single shared secret using HMAC-SHA256. It is simple and fast, which makes it ideal for local testing and for a monolith where the same service both issues and validates tokens. The catch: every party that can verify a token can also forge one, because verification requires the secret.
RS256 uses an asymmetric keypair — a private key signs, and a public key verifies. That fits distributed systems where many services (or third parties) need to check tokens but only your auth server should be able to mint them. You can publish the public key freely while keeping the private key locked down. As a rule of thumb: reach for HS256 when issuer and verifier are the same trust boundary, and RS256 when they are not. This generator focuses on HS256 because it needs nothing more than a secret string to produce a working token.
Why test tokens are not production tokens
A hand-rolled token has no revocation, no rotation, no audience binding and no refresh story — all things a real provider handles for you. Use a proper auth service (Auth0, Clerk, Cognito, Keycloak, or your own hardened server) for anything user-facing. The biggest HS256 footgun is a weak secret: short or dictionary-based secrets can be brute-forced offline once an attacker has a single token, letting them sign arbitrary tokens of their own. Use a long, high-entropy random string — you can mint one with our password generator — and never paste a live production signing secret into any browser tool.
Everything here runs in your browser via the Web Crypto API, so the secret you type stays on this page and is never transmitted. Once you have a token, paste it into the JWT decoder to confirm the header, claims and expiry decode exactly as you intended before wiring it into your tests.