JWT Generator (HS256 / HS384 / HS512)
How to Use
Pick the algorithm, fill in the header / payload / secret, and a signed JWT is produced. The `alg` field in the header auto-syncs to the selected algorithm. Choosing `alg: none` produces an unsigned token (debug only — do not use in production).
JWT Structure
A JWT is three Base64URL segments joined by dots: `header.payload.signature`. The header names the algorithm, the payload carries arbitrary claims (`sub`, `iat`, `exp`, etc.), and the signature is produced by HMAC or RSA / ECDSA. This tool supports HMAC-based algorithms (HS256/384/512). RS256 / ES256 (public-key) are intentionally not supported here, since handling private keys in a browser tool is risky.
Use Cases
- Generating test JWTs during local development
- Walking through an auth flow with a mock JWT against your own API
- Iterating on the payload shape while designing claims
- Pairing with this site's JWT decoder to verify your output round-trips
- Teaching / learning what a JWT actually looks like under the hood
Security Notes
Signing happens in-browser via Web Crypto, but **don't paste real production secrets while screen-sharing** — anyone watching can see them. Also, JWT verifiers that accept `alg: none` are a classic vulnerability; in production, always pin verification to the specific algorithm you expect.
FAQ
Is my secret key sent anywhere when I generate a token?
No. Signing is performed locally with the Web Crypto API, so the secret and payload never leave your browser — there is no upload, logging, or storage. The main caveat is screen-sharing: the secret is visible on screen even though it is not transmitted, so don't paste real production secrets in that situation.
Which signing algorithms are supported?
HMAC-based algorithms HS256, HS384, and HS512, plus `none` for unsigned tokens. Public-key algorithms like RS256 and ES256 are intentionally excluded because handling private keys in a browser tool would be risky.
What does the `alg: none` option do, and is it safe to use?
It produces an unsigned token with an empty signature segment, useful only for debugging. Never use it in production: verifiers that accept `alg: none` are a well-known vulnerability, so always pin verification to a specific algorithm.
Do I have to set the `alg` field in the header myself?
No. The header's `alg` field auto-syncs to whichever algorithm you select, so it always matches the signature being produced and you don't risk a mismatch.
Can I add standard claims like iat or exp to the payload?
Yes — the payload is free-form JSON, so you can include any registered claims such as sub, iat, or exp. There's also a toggle to set iat to the current time automatically when you generate the token.