Fast, practical, browser-based developer tools
Generate JWT tokens online using custom header, payload, algorithm, and secret values directly in your browser. This tool is useful for testing authentication flows, API development, demos, and debugging token-based systems.
JWTs are commonly used for authentication, authorization, and API communication. This tool helps developers create sample tokens quickly for local development, demos, authentication testing, and token-based debugging workflows.
This JWT generator is useful for local development, debugging, demos, and test environments. Be careful with secrets and production credentials when using browser-based tools.
For more details about site usage and analytics, read our Privacy Policy.
Edit the header JSON and payload JSON, choose an algorithm, optionally enter a secret for HS256, then generate the token. You can then copy the JWT for use in testing and debugging workflows.
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
Read this before anything else. This page signs HS256 tokens using the secret you type, and that signing happens entirely in the browser. The secret is present in the page. That makes this an excellent tool for learning how tokens are built and for generating test fixtures — and a completely wrong place to mint real production tokens. A production signing secret should live on a server, never be pasted into a web page, and never leave your control. Use test secrets and disposable payloads here.
Structurally, a JWT is three Base64url parts — header.payload.signature. The
header names the algorithm, the payload holds the claims, and the signature is computed over
the first two with the key. Only the signature needs a secret to produce; the header and
payload are plainly readable to anyone.
Signing a JWT proves two things to a verifier: the token was created by someone holding the secret, and it has not been altered since. It proves nothing about secrecy. The payload is encoded, not encrypted, so every claim you put in the token is readable by anyone who receives it — paste any token into a decoder and see for yourself.
So a JWT is the right tool for carrying claims you are happy for the bearer to read (a user
ID, roles, an expiry) and the wrong place for anything sensitive. Always include an
exp claim so the token cannot be replayed forever, and remember that on the
verifying side, checking the signature is only half the job — the claims (exp,
nbf, iss, aud) must be validated too.
HS256 is symmetric: the same secret both signs and verifies, and its security rests
entirely on that secret being strong. If you sign with a short or
dictionary secret like secret or password123, an attacker who
captures a single token can brute-force the secret offline — tools like hashcat tear through
weak JWT secrets in seconds — and then forge any token they want. Use a long, random secret
of at least 256 bits for HS256.
Symmetry also has an architectural cost: everyone who can verify an HS256 token can also sign one, because it is the same key. When one service issues tokens that many services verify, an asymmetric algorithm like RS256 or ES256 is a better fit — the issuer holds the private signing key and everyone else gets the public key, which can only verify.
This tool can also emit alg:none tokens — a header of none and an
empty signature. They are handy when you just want to shape a payload and inspect it. But a
real service must never accept an alg:none token: doing so
means anyone can hand-craft a token with any claims and be believed, since there is no
signature to check. Pin the expected algorithm on the verifying server so a token can never
downgrade itself to none.
No. It signs in the browser using the secret you type, which means the secret is exposed in the page. A production signing key belongs on a server and must never be pasted into a web tool. Use this for learning and test fixtures with throwaway secrets.
No. It is Base64url-encoded JSON, readable by anyone holding the token. The signature protects the payload from being altered, not from being read, so never put secrets or sensitive personal data inside a JWT.
That whoever created it held the signing key and that the contents have not changed
since. It does not prove the token is unexpired or meant for your service — the verifier
still has to validate the exp, iss, and aud claims.
HS256 (symmetric) is fine when the same party signs and verifies. When one issuer's tokens are verified by many services, prefer RS256 or ES256: the issuer keeps the private key and everyone else gets a public key that can only verify, not forge.
Because HS256's whole security is the secret. A short or common secret can be brute-forced offline from one captured token, after which the attacker can forge valid tokens at will. Use a random secret of at least 256 bits.
Only local testing where you want to shape and read a payload without signing. A
production server must reject alg:none outright and pin the expected
algorithm, because an unsigned token lets anyone assert any claim.