JWT Generator

Build a JWT, fill in the header and payload, paste the secret or PEM key, and get a signed token. Useful for testing your own verifier, simulating user tokens, or producing a token with a specific exp time without writing code. Uses the same WebCrypto-backed signer as the JWT Decoder's generate mode.

How to use the JWT Generator

Pick an algorithm, edit the payload JSON, paste the secret (HMAC) or private key (RSA/EC). The "Set iat/exp" button fills in current-time claims so the generated token verifies as fresh. Output is a fully signed JWT ready to paste into Authorization headers or test inputs.

Building a signed JWT by hand

A JSON Web Token is three Base64url parts joined by dots: a header naming the algorithm, a payload of claims, and a signature over the first two. The signature is what makes the token trustworthy — with an HMAC algorithm (HS256) it is a keyed hash using a shared secret; with RSA (RS256) or ECDSA (ES256) it is a real digital signature from a private key, verified later with the matching public key. This tool assembles the parts and signs them with WebCrypto.

Generating tokens by hand is mostly a testing aid: you can mint a token with a specific exp, a particular sub, or a deliberately malformed claim to see how your verifier reacts. The set-iat/exp helper stamps current-time claims so the token reads as fresh. To inspect an existing token instead, the JWT decoder pulls a token apart and checks its signature.

Common use cases

  • Testing your verifier — mint tokens with known claims to confirm your auth middleware accepts and rejects correctly.
  • Expiry handling — produce an already-expired or far-future token to test how your code treats exp.
  • Simulating users — create a token for a specific subject or role without going through a full login.
  • Algorithm checks — compare how your system handles HS256 versus RS256 signed tokens.
  • Local development — generate a valid bearer token to paste into an Authorization header while testing an API.

Frequently asked questions

When should I use HS256 versus RS256?

HS256 uses one shared secret, so anyone who can verify can also sign — fine when the same service issues and checks tokens. RS256 (or ES256) signs with a private key and verifies with a public one, which is what you want when many services need to verify but only one should issue.

Are tokens generated here safe to use in production?

Treat them as test tokens. The signing happens in your browser, but pasting a real production secret or private key into any web page is a bad habit. Mint production tokens in your own backend.

What claims should a JWT include?

Common registered claims are iss (issuer), sub (subject), aud (audience), exp (expiry), and iat (issued-at). Add your own claims for roles or tenant IDs, but keep the payload small since it travels on every request.

Is the payload encrypted?

No. A signed JWT is only Base64url-encoded, so anyone can read the claims. The signature prevents tampering, not reading. Never put secrets in the payload; if you need confidentiality you need JWE, a separate standard.
Embed this tool on your site

Free to embed, no attribution required (but appreciated). Paste this where you want the tool to appear: