JWT Generator
Build and sign a JSON Web Token locally — header, claims, and HMAC signature.
Your signing secret never leaves this browser
Signing runs entirely on your device using the browser's built-in WebCrypto API. The secret, the header, the payload and the finished token are never uploaded, logged, or sent to any server — there is no network request in this tool at all. Nothing is stored after you close the tab.
Signing
RS256, RS512, ES256, ES384, PS256 are not supported: they sign with an asymmetric private key, which means uploading or pasting a PEM key file and a different interface. Three HMAC algorithms done correctly beats eight done badly.
The same secret must be configured on the server that verifies this token. Random generates
a cryptographically random key sized to the selected algorithm (32 / 48 / 64 bytes) via
crypto.getRandomValues.
Header
Kept in sync with the algorithm select. typ is conventionally JWT.
Payload
Standard claims
The payload is encoded, not encrypted
Anything you put in the payload is readable by anyone holding the token — Base64URL is a reversible encoding, not a cipher. Paste any JWT into a decoder and the claims are plain text in a fraction of a second. Never put passwords, API keys, card numbers, health data, government IDs, or anything else confidential in a JWT.
Signed token
JSON is minified before signing (whitespace removed), exactly as server-side JWT libraries do — so the same header, payload and secret always produce a byte-identical token. Open this token in the JWT Decoder →
How to Use the JWT Generator
- Pick a signing algorithm — HS256 is the right default unless your server expects otherwise.
- Enter the shared secret your server uses to verify tokens, or click Random to generate a fresh one.
- Edit the payload directly, or use the claim buttons to set
iss,sub,aud,jti,iatandexp. - The token is signed and re-signed automatically as you type — no submit button.
- Click Copy to copy the token, then paste it into an
Authorization: Bearerheader. - Round-trip it through the JWT Decoder to confirm the claims decode the way you expect.
Click Load sample to fill in the canonical example token — header
{"alg":"HS256","typ":"JWT"}, payload {"sub":"1234567890","name":"John Doe","iat":1516239022}, secret your-256-bit-secret.
It produces the reference token published in every JWT tutorial, which is a quick way to confirm this tool signs
the same way your library does.
What a JWT is Made Of
A JSON Web Token is three Base64URL-encoded strings joined by dots. Each part has one job, and none of them involve encryption.
- Header — a tiny JSON object naming the signing
algorithm and token type, e.g.
{"alg":"HS256","typ":"JWT"}. It may also carrykid, a key ID that tells the verifier which of several keys to use. - Payload — the claims. Registered claims are the
short standard names from RFC 7519:
iss(who issued it),sub(who it is about),aud(who it is for),exp(expiry),nbf(not valid before),iat(issued at) andjti(a unique token ID). You can add any custom claims you like alongside them. - Signature — an HMAC computed over the literal
string
base64url(header) + "." + base64url(payload)using your secret. Change one byte of either part and the signature no longer matches.
The dots matter: the signature covers the encoded text, not the parsed objects. That is why re-serializing a JWT with different key ordering or spacing invalidates it, and why you should always verify the token string you received rather than one you rebuilt.
What Signing Actually Proves
Signing a JWT gives you integrity and authenticity: a verifier holding the
secret can confirm the token was produced by someone who also holds that secret, and that not a single character
has been altered since. If an attacker flips "role":"user" to "role":"admin", the HMAC
stops matching and verification fails.
Signing gives you no confidentiality whatsoever. The header and payload are still fully readable by anyone who intercepts the token, sees it in a browser's local storage, or finds it in a server log or a URL in an analytics export. A signature is a tamper-evident seal on an envelope made of glass.
A few practical consequences. HMAC secrets are symmetric, so every service that can verify a token can also mint
one — if you need many verifiers but one issuer, you want asymmetric signing (RS256 or ES256) instead. Use a
long, random, high-entropy secret, not a memorable phrase: HS256 signatures are offline-crackable, and a weak
secret can be brute-forced from a single captured token. And because a signed token stays valid until it
expires, keep exp short and maintain a way to revoke sessions server-side.
Never Put Secrets or Personal Data in the Payload
This is the single most common JWT mistake, and it is worth stating bluntly: a JWT payload is only base64url-encoded, never encrypted. Base64URL exists to make bytes safe to put in a URL. It has no key, no algorithm choice, and no security property at all. Decoding a payload takes one line of code and no credentials.
So treat every claim as if it were printed on a postcard. That rules out passwords and password hashes, API keys and other tokens, database connection strings, full card numbers, national ID or passport numbers, health or biometric information, home addresses, and internal notes about a user. Under GDPR and similar regimes, an email address or a stable user identifier is personal data too — every intermediary that touches the token, and every log line it lands in, is now holding it.
What belongs in a payload instead: opaque identifiers your own systems can resolve, coarse authorisation facts such as a role or scope list, and the timing claims. Keep it small — the token travels on every request, and a bloated payload is a permanent tax on your latency and your header size limits. If you genuinely need the contents hidden in transit and at rest, a signed JWT is the wrong tool; look at JWE (encrypted tokens) or simply keep the data server-side behind an opaque session ID.
Specifications
- Accepts
- Text — type or paste
- Gives you
- copy to clipboard
- Where it runs
- Your browser — the file is never uploaded
- Sign-up
- None
- Cost
- Free, with no usage limits
FAQ
Is my signing secret sent anywhere?
No. The secret is read from the input box, converted to bytes, and passed to your browser's built-in WebCrypto API to compute the HMAC locally. This page makes no network requests while generating a token, stores nothing, and has no analytics on the secret field. You can confirm it yourself by opening your browser's Network tab while typing, or by disconnecting from the internet — the tool keeps working.
Why are only HS256, HS384 and HS512 supported?
Those three are HMAC algorithms: they sign with a shared secret you can simply type into a text box. RS256, PS256 and ES256 sign with an asymmetric private key, which means handling a PEM or JWK key file, parsing it, and a completely different interface — plus pasting a production private key into a web page is a habit worth discouraging. Supporting three algorithms correctly is more useful than supporting eight of them badly.
Is a JWT payload encrypted?
No, and this trips people up constantly. The payload is Base64URL-encoded, which is a reversible text encoding with no key involved — anyone holding the token can read every claim instantly. The signature protects the token from being modified; it does not hide anything. Never place passwords, keys, card numbers, or personal data in a JWT payload.
What does the signature actually guarantee?
That the token was created by someone who knows the secret, and that neither the header nor the payload has changed since. It guarantees integrity and authenticity, not confidentiality. Note that with HMAC the secret is symmetric, so anyone who can verify a token can also forge one — which is why you should never share an HMAC secret with third parties.
How long should the expiry be?
Short. Fifteen minutes to an hour is typical for an access token, because a signed token stays valid until exp regardless of whether the user logged out or had their access revoked. Longer-lived refresh tokens should be stored server-side so they can be invalidated. If you find yourself issuing 30-day access tokens, you probably want a session store instead.
Can I use this token in production?
You can, and the output is a standards-compliant RFC 7519 token that any JWT library will verify. But generate production secrets with your own tooling and keep them in a secret manager rather than typing them into any web page, this one included. This generator is best used for testing an API, reproducing a bug, seeding a local environment, or learning how the pieces fit together.
Why does my token differ from the one my library produced?
Almost always JSON serialization. The signature covers the exact encoded bytes, so key ordering and whitespace change the result — {"alg":"HS256","typ":"JWT"} and {"typ":"JWT","alg":"HS256"} produce different tokens even though both are valid. This tool minifies your JSON and preserves your key order. A different-looking token is not necessarily an invalid one: verify it rather than comparing strings.