Skip to main content
Toollyz

Search tools

Search for a command to run...

JWT Generator

Build and sign JWTs with custom header / payload / secret via the Web Crypto API. HS256, HS384 and HS512 supported. Claim inspector calls out registered claims. 100% client-side — secrets never touch a server.

What is the JWT Generator?

JWT Generator builds and signs JSON Web Tokens in your browser using the Web Crypto API's HMAC primitive (`crypto.subtle.sign`). Edit the claims as JSON, pick the algorithm (HS256, HS384 or HS512), set a shared secret (raw UTF-8 or base64url-encoded raw bytes), and the tool produces a valid `header.payload.signature` token with each segment shown separately and copyable. A claim inspector highlights the registered claims (`iss`, `sub`, `aud`, `exp`, `nbf`, `iat`, `jti`) and explains what each one means — useful when learning the RFC 7519 vocabulary. We deliberately limit the tool to HMAC algorithms: RS256 / ES256 require importing a real private key, and pasting one into any webpage is a security risk we won't encourage. Use a server-side library for RS / ES signing. Claims are stringified with sorted keys for reproducible output.

How to use it

  1. Edit the claims JSON — start with the sample (`iss`, `sub`, `iat`, `exp`, `name`, `scope`) or paste your own.
  2. Pick the HMAC algorithm (HS256 default; HS384 / HS512 for stronger digests).
  3. Set the shared secret. Tick 'secret is base64url-encoded raw bytes' if your key is binary.
  4. Copy the signed JWT or any of its three segments individually for inspection.

Benefits

  • Signed entirely via the Web Crypto API — `crypto.subtle.sign` with HMAC + chosen hash.
  • Three algorithms (HS256, HS384, HS512) cover the workhorse symmetric JWT use cases.
  • Claims editor accepts arbitrary JSON; output is stably stringified for reproducibility.
  • Each of the three JWT segments (header, payload, signature) shown separately with copy buttons.
  • Claim inspector explains the registered RFC 7519 claims (`iss`, `sub`, `aud`, `exp`, `nbf`, `iat`, `jti`).
  • Base64url-encoded raw-byte secret mode for binary keys.
  • Live re-sign on every change — no 'Sign' button to click.
  • Runs 100% in your browser — secrets and claims never leave the device.

Frequently asked questions

Which algorithms are supported?

HS256, HS384 and HS512 — the symmetric (shared-secret) HMAC algorithms standardised by RFC 7518.

Why not RS256 / ES256?

Asymmetric algorithms require importing a private key (typically as PEM). Pasting a real RSA / EC private key into any webpage is a security risk we won't encourage. Use a server-side library — Node `jsonwebtoken`, Go `golang-jwt`, Python `pyjwt` — for those.

Is my secret sent anywhere?

No. The signing happens via `crypto.subtle.sign` entirely in your browser. Toollyz has no server that ever sees your secret or the claims.

What's the difference between 'secret as text' and 'base64url raw bytes'?

Most JWT examples use a UTF-8 string as the secret. But the spec says the HMAC key is raw bytes — if you generated a 32-byte random key with `openssl rand -base64url 32`, tick the box so we decode the base64url back to bytes before signing.

Does it verify existing JWTs?

No — this tool only signs. To verify a JWT, use the companion JWT Decoder tool, which displays the header, payload and signature so you can re-sign here with the same secret and compare.

Why is the same input producing different JWTs sometimes?

It shouldn't — claims are stably stringified with sorted keys before signing, so the same input always yields the same JWT. If you see drift, check whether `iat` is being set to `Math.floor(Date.now() / 1000)` and pinning that value.

What's `iat` vs `exp` vs `nbf`?

`iat` is when the token was minted, `nbf` is the earliest time it's valid, `exp` is when it expires — all in UNIX seconds. Most APIs care about `exp` (must be in the future) and sometimes `nbf` (must be in the past).

Does the algorithm in the header matter?

Yes — we always set the `alg` field of the header to match the selected algorithm. If you edit the header JSON to claim a different `alg`, signing still uses what's selected here, so the result would fail verification.

Will this work with auth0 / firebase / supabase?

Yes if they accept HS256/HS384/HS512 tokens. Most platforms use RS256 with platform-issued keys, so generated tokens here won't verify against their public keys.

Can I generate keys for the secret?

Use the Session ID Generator or API Key Generator with the base64url encoding and 32-byte body length — that produces a strong HS256 key. Then paste it here with the base64url toggle on.

Is anything stored?

Only locally — your last claims, algorithm, secret choice and base64url flag are persisted in localStorage on this device. Toollyz has no backend.