JWT Generator & Signer
Build and sign JWTs with HS256/384/512 in your browser. Edit header and payload, supply a secret, and get a ready-to-use token. Nothing uploaded.
Header
How it works
- The header and payload are encoded as Base64URL, then concatenated as
header.payload. - The signature is an HMAC-SHA2 over that string, keyed with your secret, per RFC 7519 / RFC 7515.
- Signing runs in your browser with
crypto.subtle— the secret is never sent anywhere. - Insert now / Insert exp fill common
iat/exptimestamps for testing.
About JWT Generator & Signer
JWTs are compact, URL-safe tokens used for authentication and authorization — typically a header declaring the algorithm, a payload of claims, and a signature that proves the token was issued by whoever holds the secret. HMAC-signed (HS*) tokens are symmetric: the same secret both signs and verifies, so it must live only on the server. This tool is for local testing, crafting fixtures, and understanding the format — use it alongside the JWT decoder on devops.jsonversal.com to verify what you produced.
Keep your secret out of the payload and out of the header: the header and payload of an HMAC JWT are only base64-encoded, not encrypted — anyone can read them. Never place passwords or sensitive data inside claims, prefer short-lived tokens with an exp claim, and use an asymmetric algorithm (RS256/ES256) when multiple parties must verify tokens without sharing a secret.
What is actually signed
The signature covers the ASCII bytes of `base64url(header) + "." + base64url(payload)`, keyed with your secret through HMAC-SHA2. This tool signs the raw JSON text from the textareas verbatim — it does not re-serialise — so the exact whitespace, indentation and key order you typed become part of the signed message. Reformatting the JSON after signing invalidates the token even though nothing semantically changed.
base64url drops `=` padding and maps `+` to `-` and `/` to `_`, which is what lets a JWT survive a query string, a cookie or an Authorization header unmangled. The algorithm is read from `header.alg` in your input and validated against a whitelist of HS256, HS384 and HS512. That whitelist is the defence against `alg: none` and against algorithm-confusion downgrades — never remove it.
What HS256 commits you to
HMAC-signed tokens are symmetric: the same secret issues and verifies, so every party that needs to validate a token must also be able to mint one. That is fine inside a single trust boundary — your API plus your own backend services — and structurally wrong the moment a third party must verify without being able to issue, such as a partner integration or a public API consumed by many clients. Those cases need RS256 or ES256, which this tool does not implement.
Header and payload are base64url, not encrypted. Anyone holding the token can read every claim with no key at all, so keep passwords, tokens and personal data out of both. Short lifetimes matter more than signing strength in practice: the `Insert exp` button sets `exp` to now plus 3600 seconds, a sensible ceiling for a short-lived access token and far too generous for a refresh token.
Sharp edges in the workflow
The two timestamp buttons re-serialise your payload through `JSON.stringify` with two-space indentation. That changes the signed bytes, so a signature produced before you clicked `Insert exp` no longer matches the payload sitting in the textarea — always sign again after editing. This is the single most common way to end up with a token that verifies nowhere.
The page signs whatever header you hand it, including `kid`, `jku` or `x5u`. A verifier that fetches key material referenced by an untrusted token header is exposed to SSRF and key substitution, so never take the expected algorithm or key location from the token you are verifying. Finally, this tool builds tokens but validates nothing — it will happily sign a token whose `exp` is in the past, so run the output through the JWT decoder to confirm the claims before you trust it.
Next steps
- JWT Decoder— inspect the generated token
Frequently Asked Questions
How do I create a JWT token?
Can I sign with RSA or ECDSA?
Is my data sent to a server?
Do I need an account or API key?
Can I use these tools offline?
All processing happens in your browser. No uploads, no tracking, no servers. Your API keys, configs, and private payloads stay private — 100% client-side.