snaptxt.app

JWT Generator

Sign JSON Web Tokens with HS256, HS384, HS512, RS256, RS384, RS512, ES256, or ES384. Live preview, browser-only — your secret never leaves the page.

Algorithm
Header (optional overrides)

alg and typ are set for you. Anything here merges on top.

Payload (claims)
HMAC secret

HMAC uses the raw bytes of this string. For HS256, RFC 2104 recommends a key at least as long as the hash output (32 bytes).

Signed JWT
Fill in the payload and key — token appears here.

Your secret never leaves your browser.

Signing uses the native Web Crypto API. The HMAC secret or PEM private key stays on your device — there is no server side. Safe to paste real keys while debugging or building integrations.

How to use it

  1. 1Pick a signing algorithm: HS* uses an HMAC secret string; RS* and ES* use a PEM-encoded private key.
  2. 2Edit the payload JSON with your claims (sub, iss, aud, custom data). Use the iat = now and exp +1h / +24h buttons to add timestamps without doing the math.
  3. 3For RS / ES algorithms, hit Generate keypair to create a fresh private key in your browser, or paste your own PEM.
  4. 4The signed JWT updates live as you type. Click Copy token to grab it, or open it in the JWT Decoder to verify.

Common use cases

  • Create a test token for an authentication endpoint while building or debugging an API.
  • Mint a short-lived JWT to reproduce a bug filed against your auth flow.
  • Generate a token with a specific exp claim to test how your service handles expiry.
  • Sign a payload with a known key and pass it through your verifier as an integration test.
  • Hand a teammate a sample token plus the same key so both sides agree on the algorithm and claim shape.

Frequently asked questions

Is my secret or private key uploaded anywhere?
No. Signing uses the native Web Crypto API in your browser. The HMAC secret or PEM private key stays on your device — safe to paste real keys while debugging.
Which algorithms are supported?
HS256, HS384, HS512 (HMAC with a shared secret); RS256, RS384, RS512 (RSASSA-PKCS1-v1_5); ES256 and ES384 (ECDSA over P-256 and P-384). Eight total — the JWA-defined algorithms that browsers support natively.
What key format does it expect for RS / ES?
PEM-encoded PKCS#8 private keys — the format that begins with `-----BEGIN PRIVATE KEY-----`. Use the Generate keypair button to create one in-browser, or convert from openssl with `openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in your-key.pem`.
What's the difference between HS and RS?
HS (HMAC) uses one shared secret — anyone who can verify can also sign. RS / ES (asymmetric) uses a private key to sign and a public key to verify, so you can hand the public key to consumers without giving them the power to mint new tokens. RS / ES are the right choice for anything beyond a closed internal service.
Can I override fields in the JWT header?
Yes. Anything in the Header textarea merges on top of the auto-generated alg and typ — useful for adding kid (key id), x5t, or custom header claims your verifier expects.
Does the token expire?
Only if you include an exp claim. The exp +1h and exp +24h buttons add one for you. With no exp, the token is valid forever — usually a bad idea outside of testing.
Can I verify a token here?
Paste the signed JWT into the JWT Decoder to inspect header and payload. Verification (checking the signature against a key) is a separate flow — most servers do this; manual verification is rare outside of debugging.