Generate secure JSON Web Tokens with custom headers, payloads and claims. Everything runs locally in your browser.
Never use production secrets while testing JWT tokens online. Anything typed here stays in this tab, but a real signing secret should not be handled outside the system that owns it. Generate a throwaway one instead. Tokens made here are for development, testing and learning — always verify them on your server.
Algorithm
HMAC with SHA-256. The most widely used JWT algorithm. One shared secret both signs and verifies, so everyone who can check a token can also mint one.
Secret
No secret yet.
These are written into the payload each time they change. Custom claims you add in the payload editor are kept; only the fields below are overwritten.
Who created and signed this token.
Who the token is about — usually a user id.
Who the token is intended for. A recipient should reject a token not addressed to it.
A unique id for this token, used to prevent replay.
Sets exp to this far ahead of the moment the token is generated.
Sets nbf. A verifier must reject the token before this moment.
For development and testing — verify signatures on your server.
Generated in your browser — nothing is uploaded.
Everything happens locally in your browser. Your secret key and JWT are never uploaded or stored.
What is a JWT generator?
A tool that builds a JSON Web Token from three things you supply: a header saying how it will be signed, a payload of claims, and a secret to sign with. The result is a string you can paste into an Authorization header, a test fixture, or a decoder to see what it looks like from the other side.
It exists because writing one by hand is tedious and easy to get wrong — base64url is not base64, the timestamps are seconds rather than milliseconds, and the signature covers exactly the header and payload as encoded, not as you typed them.
Everything here happens in your browser using the platform’s own WebCrypto. Nothing is uploaded, and the secret goes away when you close the tab. Even so, this is a tool for development, testing and learning — production tokens should be issued by your own system, with a secret that has never been typed into a browser.
How JWT generation works
Four steps, and the order matters.
1. Encode the header. Serialise it to JSON and base64url-encode it. base64url swaps +/ for -_ and drops the padding.
2. Encode the payload the same way.
3. Join them with a dot. That string — not the original JSON — is what gets signed. This is why re-formatting the JSON afterwards invalidates the token.
4. Sign it and append the result. HMAC the joined string with your secret, base64url-encode the digest, and add it after another dot.
Two fields, usually. alg names the signing algorithm and typ is JWT. This tool writes alg from your chosen algorithm rather than trusting what is typed, because a header that disagrees with the signature fails verification for reasons nobody can see.
The payload
The claims. Registered ones such as sub and exp mean the same thing everywhere; everything else is yours. Keep it small — the token travels on every request, and it is not encrypted, so nothing secret belongs in it.
The signature
Proof that whoever made the token held the secret, and that nothing has changed since. With HMAC the same secret signs and verifies, which means anyone who can check your tokens can also mint them — worth remembering before sharing a secret across services.
Supported signing algorithms
None (unsigned)
No signature at all. Legal per RFC 7519 §6, useful for testing a decoder, and something production systems must reject outright — it is the shape of a classic forgery attack.
HS256
SHA-256 · minimum key 32 bytes
HMAC with SHA-256. The most widely used JWT algorithm. One shared secret both signs and verifies, so everyone who can check a token can also mint one.
HS384
SHA-384 · minimum key 48 bytes
HMAC with SHA-384. A longer digest than HS256 for the same shared-secret model. Rarely needed unless a policy requires it.
HS512
SHA-512 · minimum key 64 bytes
HMAC with SHA-512. The longest digest of the three, and the largest signature. Same trade-off as HS256.
All three HMAC variants are symmetric: one shared secret both signs and verifies. That is fine when the issuer and the verifier are the same system, and a problem when they are not — every service that can check a token can also forge one. Asymmetric algorithms such as RS256 solve that by splitting the key in two, which is why they are the right choice for public APIs, and why they are not offered here: signing would mean handling a private key in a web page.
Standard JWT claims
RFC 7519 registers these seven. All are optional, and all mean the same thing in every system — which is what makes a token from one issuer readable by another.
issIssuer
Who created and signed this token.
subSubject
Who the token is about — usually a user id.
audAudience
Who the token is intended for. A recipient should reject a token not addressed to it.
expExpiration
After this moment the token must be rejected.
nbfNot before
Before this moment the token must be rejected.
iatIssued at
When the token was created.
jtiJWT ID
A unique id for this token, used to prevent replay.
exp, nbf and iat are Unix timestamps in seconds. Passing milliseconds is the most common mistake in hand-written JWT code, and it produces tokens that expire in the year 56000 — worth checking the number against a Unix timestamp converter before you trust it.
How to generate a JWT
1. Pick an algorithm. HS256 unless you have a reason otherwise. Choose None only to demonstrate what an unsecured token looks like.
2. Get a secret. Press Generate for a random one sized for the algorithm. Do not paste a production secret — the page keeps it locally, but a real signing key should not leave the system that owns it.
3. Fill in the standard claims. Issuer, subject and audience identify the token; the expiry window sets exp.
4. Add your own claims. Anything else the receiving system needs — a role, a tenant, a set of permissions. Nothing secret.
5. Read the token. It regenerates as you type. The three parts are coloured so you can see where each begins.
6. Check it. Paste it into the JWT decoder to see it from the receiving end, then verify it properly with a library on your server.
JWT security best practices
Use a strong secret. RFC 7518 requires a key at least as long as the digest — 32 bytes for HS256, 64 for HS512. Words and short phrases are brute-forced in seconds, and then anyone can mint tokens your server trusts — the password generator will put an entropy figure on a candidate before you rely on it.
Keep tokens short-lived. A JWT usually cannot be revoked, so its lifetime is how long a stolen one stays useful. Minutes for access tokens, with a revocable refresh token behind them.
Never expose the secret. Not in client code, not in a repository, not in a screenshot — and not in an online tool. Anyone holding it can issue tokens indistinguishable from yours.
Always use HTTPS. A bearer token is a password in transit. Anyone who intercepts it can use it.
Verify signatures server-side, and pin the algorithm.Decide which algorithm you accept rather than trusting the header’s alg, and reject none outright. Trusting the header is how algorithm-confusion attacks work.
Check the claims too. A validly signed token can still be the wrong one — confirm iss, aud, exp and nbf before trusting it.
Put nothing secret in the payload. It is base64url, not encryption. Anyone holding the token can read every claim.
Common JWT use cases
User authentication
After a sign-in, issue a token the browser sends with each request instead of the password.
OAuth 2.0
Access tokens are frequently JWTs carrying the granted scopes and the client they were issued to.
REST APIs
A bearer token in the Authorization header is the default way to authenticate a request.
Single sign-on
One identity provider signs a token that several applications accept, so a user signs in once.
API authorization
Roles and scopes travel in the payload, so a service decides what a request may do without a lookup.
Microservices
Short-lived signed tokens let one internal service prove its identity to another without shared passwords.
Frequently asked questions
Is this JWT Generator free?
Yes. Every algorithm, the claims builder, the templates, search, copy and download are free, with no account and no limit on how many tokens you create.
Is my JWT uploaded?
No. The token is built and signed by JavaScript running in your browser, using the platform's own WebCrypto. Nothing is sent to a server, nothing is stored and nothing is logged. You can disconnect from the network after the page loads and it keeps working.
Is my secret key stored?
No. It lives in the page's memory for as long as the tab is open and goes away when you close it. It is not written to local storage, not put in the URL and not sent anywhere. Even so, do not paste a production signing secret here — not because this page would leak it, but because a real signing key should never leave the system that owns it.
Which algorithms are supported?
HS256, HS384 and HS512 — HMAC with SHA-256, SHA-384 and SHA-512 — plus unsigned tokens with alg: none. All three HMAC variants use a single shared secret that both signs and verifies.
Why is RS256 not supported?
RS256 and the other asymmetric algorithms sign with a private key, and a page that asked you to paste a private key into a form would be teaching a genuinely dangerous habit. HMAC uses a shared secret, which is at least the kind of thing you can generate here and throw away. For RS256, use your language's JWT library on a machine that already holds the key.
Can I create unsigned JWTs?
Yes — choose None. The result is an unsecured JWT as defined in RFC 7519 §6: three parts, with the third one empty. They are useful for testing a decoder or demonstrating the format, and production systems should reject them outright, because accepting one is a well-known forgery route.
Can I generate custom claims?
Yes. Anything you put in the payload becomes a claim, of any JSON type — strings, numbers, booleans, arrays and nested objects all work. The standard claims have a form of their own, and the two are combined: your custom claims are kept and the standard ones are written over the top.
How are the timestamps calculated?
iat is the moment the token is generated, exp is that moment plus the window you choose, and nbf is that moment plus its own window. All three are Unix timestamps in seconds, not milliseconds — the most common bug in hand-written JWT code. Pressing Generate refreshes them.
Can I download generated JWTs?
Yes. The toolbar downloads the token as a .txt file, and the header and payload can each be saved as JSON from their own editor. Everything can also be copied to the clipboard.
Can I verify generated tokens?
Not here — this tool signs, and the JWT Decoder next door reads. Neither verifies, for the same reason: verification needs a key, and a web page is the wrong place to hold one. To check a token you generated, feed it and the same secret to your language's JWT library on your server.
How strong should my secret be?
RFC 7518 requires a key at least as long as the digest: 32 bytes for HS256, 48 for HS384 and 64 for HS512. The tool measures what you have typed and says whether it clears that bar. A short, guessable secret is the single most common JWT failure — once it is brute-forced, anyone can mint tokens your server will trust.
Why does the header's alg change when I switch algorithms?
Because the header has to describe what actually signed the token. If it said HS512 while the signature was made with HS256, verification would fail for a reason nobody could see from the outside. The tool writes the selected algorithm into the header rather than trusting whatever is typed there.
Are these tokens safe to use in production?
No. This tool is for development, testing and learning. A production token should be issued by your own system, with a secret that has never been typed into a browser, and it should always be verified server-side. Treat anything generated here as a fixture.
What is the difference between this and the JWT Decoder?
This one builds and signs a token from a header, a payload and a secret. The decoder reads an existing token and shows what is inside it, without a key and without checking the signature. Together they cover both directions, and neither ever claims a token is authentic.
Are there keyboard shortcuts?
Ctrl/Cmd+Enter regenerates the token with fresh timestamps, Ctrl/Cmd+Shift+C copies it, Ctrl/Cmd+Shift+D downloads it, Ctrl/Cmd+Shift+L loads the next template and Ctrl/Cmd+Shift+Delete clears everything. Ctrl/Cmd+F opens the search, and Escape closes it.
Keep going
Tools that pair with this one
Same privacy model — everything below runs in your browser too.
