JWT Generator
Create and encode a JSON Web Token in your browser. Edit the header (alg — HS256, HS384 or HS512 — and typ), write the payload claims (sub, iss, aud, exp, iat), generate a strong random signing secret, and get a ready-to-use HMAC-signed token. Signing uses the Web Crypto API — your header, payload and secret are never sent to any server.
Everything runs in your browser. The header, payload and secret you enter are signed locally with the Web Crypto API and are never sent to any server — no network request is made. Build test tokens here; keep real signing keys on your server.
Header
Algorithm & token type{
"alg": "HS256",
"typ": "JWT"
}Signing secret
HMAC key (symmetric)The same secret both signs and verifies an HS256 token. The “Generate” button uses crypto.getRandomValues for a 256-bit random key. A short or guessable secret can be brute-forced offline from a single token.
Payload
Claims (JSON)Time claims (exp, iat, nbf) are NumericDate — seconds since 1970-01-01 UTC. The quick-add buttons use your current clock.
What this tool is
- A free, in-browser JWT generator and encoder: set the header (alg + typ), write the payload claims as JSON, supply a signing secret, and get a complete signed JSON Web Token.
- Signs with HS256, HS384 or HS512 using the browser’s Web Crypto API (HMAC) — the signature is computed over base64url(header).base64url(payload), exactly per RFC 7515 and RFC 7519.
- Quick-add buttons stamp the standard registered claims — sub, iss, aud, iat, nbf and a relative exp like "+1h" or "7d" — so you do not have to hand-compute NumericDate timestamps.
- A one-click "Generate" button creates a strong, random 256-bit signing secret from crypto.getRandomValues — a proper CSPRNG, not Math.random.
- Everything happens client-side. The header, payload and secret never leave your browser and no network request is made. This builds TEST tokens — keep production signing keys on your server.
How a JWT is built
A JSON Web Token is three base64url-encoded segments joined by dots: header.payload.signature. The header is a small JSON object naming the signing algorithm (alg) and token type (typ); the payload is a JSON object of claims; and the signature is produced by signing the string base64url(header) + "." + base64url(payload) with a key. This generator does exactly that: it encodes your header and payload, runs the HMAC, and appends the base64url signature.
base64url is the URL-safe variant of Base64 (+ and / become - and _, and the = padding is stripped), so a token can travel safely in a URL or an HTTP header.
HS256, HS384 and HS512
This tool signs with the HS family — HMAC with SHA-256, SHA-384 or SHA-512. These are symmetric: one shared secret both signs and verifies the token. They are simple and fast, which is why they are so common, but the verifier holds the signing key, so the security of an HS token rests entirely on the secret being long and random. For tokens that cross a trust boundary (an identity provider issuing to many services), an asymmetric algorithm such as RS256 or ES256 is usually better — those require a private key and are deliberately out of scope for an in-browser tool.
The registered claims
RFC 7519 reserves a handful of claim names with defined meanings. The quick-add buttons in the tool insert these for you:
| Claim | Name | Meaning |
|---|---|---|
| iss | Issuer | Who created and signed the token (often a URL or service name). |
| sub | Subject | The principal the token is about — typically a user ID. |
| aud | Audience | The recipient(s) the token is intended for. Verifiers reject a mismatched aud. |
| exp | Expiration | NumericDate after which the token must be rejected. Always set one. |
| nbf | Not before | NumericDate before which the token is not yet valid. |
| iat | Issued at | NumericDate when the token was created. |
| jti | JWT ID | A unique identifier, used to prevent replay or allow revocation. |
Generate a strong signing secret
For HS256 the signing secret should carry at least 256 bits of entropy — 32 random bytes. The tool's “Generate” button draws those bytes from crypto.getRandomValues, the browser's cryptographically secure RNG, and base64url-encodes the result, giving you a secret that is not derived from a password or a weak source. If you bring your own secret, make it long and random: a weak HS256 secret can be recovered offline from a single captured token, after which an attacker forges valid tokens freely.
Security note — read before using a real token
- A JWT is not encrypted. The payload is only base64url-encoded — anyone holding the token can read every claim. Never put passwords, keys or sensitive personal data in it.
- alg: "none" is dangerous. An unsigned token lets anyone mint a valid-looking JWT. This tool always signs, and a correct verifier must pin the expected algorithm and reject "none".
- Keep signing keys server-side. This generator is for building test tokens locally. Do not paste a production signing key into any web page, and sign real tokens in your backend.
References: JWT (RFC 7519), JWS (RFC 7515) and the JSON Web Algorithms (RFC 7518). This tool is an independent implementation and is not affiliated with any JWT library or vendor.
Frequently asked questions
What does this JWT generator do?
It builds a complete, signed JSON Web Token (a JWS) in your browser. You choose the algorithm and type in the header, write the claims you want in the payload as JSON, and provide a signing secret; the tool base64url-encodes the header and payload, computes the HMAC signature over them, and joins the three parts with dots into a finished token. It is useful for testing an API that expects a JWT, reproducing a token to debug a verifier, or learning how the pieces of a JWT fit together — all without installing a library or sending anything to a server.
Which signing algorithms are supported?
The symmetric HMAC family: HS256, HS384 and HS512, which sign and verify with a single shared secret using SHA-256, SHA-384 or SHA-512 respectively. These are implemented with the Web Crypto API (crypto.subtle), so the signing is real, standards-correct HMAC — a token produced here verifies against any conforming JWT library given the same secret. Asymmetric algorithms (RS256, ES256 and so on) need a private key and are intentionally not offered here, because pasting a production private key into a web page is a bad habit; use this tool for HMAC test tokens and sign asymmetric tokens on your server.
Is it safe to create a JWT here?
The generation itself is completely safe in the sense that nothing you type is transmitted: the header, payload and secret are processed entirely in your browser with no network request, so they are not logged or stored anywhere off your machine. The real caution is about what you build: a JWT is signed, not encrypted, so anyone who gets the finished token can read every claim in the payload. Treat the tokens you generate as readable, never put secrets in the payload, and do not paste a real production signing key into any website — mint test tokens here and keep live keys server-side.
How do I pick a good signing secret?
For HS256 the secret should have at least as much entropy as the hash output — 256 bits (32 bytes) of randomness. A short phrase or a dictionary word is weak: an attacker who captures one token can brute-force a weak HS256 secret offline and then forge valid tokens at will. Use the "Generate" button, which draws 32 random bytes from crypto.getRandomValues (a cryptographically secure RNG) and base64url-encodes them, or paste your own high-entropy secret. The same secret is used to verify the token later, so store it somewhere safe.
What are the registered claims like exp, iat and sub?
RFC 7519 defines a set of standard ("registered") claim names so verifiers interpret them consistently: iss (issuer), sub (subject — who the token is about), aud (audience — who it is for), exp (expiration time), nbf (not-before time), iat (issued-at time) and jti (a unique token ID). The three time claims are NumericDate values — seconds since 1970-01-01 UTC — which is why the quick-add buttons compute them from your clock and the relative "exp +1h" helper exists. A complete server-side check verifies the signature and then validates exp, nbf, aud and iss; a valid signature alone does not make a token current or meant for you.