Use the free JWT Generator HS256 below: your data never leaves your browser — all work happens on your device, and nothing is uploaded to any server.
JWT: the little token that carries its own proof
When you log in to a modern website, the server often hands you a JSON Web Token, a JWT. Your browser stores it and sends it back with every request, and the server trusts it without looking anything up in a database. That works because the token carries its own proof: a signature that only the server could have made. If anyone tampers with the token, the signature stops matching, and the server rejects it. The tool on this page creates and verifies HS256 tokens, the most common signed JWT type, entirely in your browser.
A JWT has three parts, joined by dots. The header says which algorithm and token type are used, usually {“alg”:”HS256″,”typ”:”JWT”}. The payload carries claims: who the user is, when the token was issued, when it expires, and whatever else the application needs. The signature is an HMAC-SHA256 of the header and payload, computed with a secret key that only the server knows. Each part is base64url-encoded, which is base64 with URL-safe characters and no padding, so the whole token is safe to put in an HTTP header or a URL.
Creating a token with this tool
Edit the header and payload JSON, type a secret, and press Generate. The tool signs the token with Web Crypto, the same cryptographic engine your browser uses for secure websites, and shows you the full token plus the decoded payload. The classic example is already filled in: a payload naming John Doe, issued at a fixed time, signed with the secret “your-256-bit-secret”. Its token is the famous example from the JWT standard’s documentation, and producing exactly that token is a good check that an implementation is correct. This tool reproduces it.
The verify function works the other way. Paste any HS256 token and the secret, and the tool decodes the header and payload and checks the signature. A valid signature means the token was signed with that secret and has not been altered since. An invalid signature means either the wrong secret or a tampered token. Note that verification needs the secret: anyone can decode a JWT’s payload without any key, because base64 is encoding, not encryption, but only the key holder can verify the signature.
What JWTs are good for, and what they are not
JWTs shine for stateless authentication. A server that can verify a signature does not need to store sessions or query a database for every request, which makes scaling easier. They are also handy for passing claims between services: one service issues a token, another verifies it, and both trust the same secret or public key. Short-lived access tokens, often paired with longer-lived refresh tokens, are the standard pattern.
But JWTs have real limits. A token cannot be easily revoked before it expires, because the server does not track it; the usual fix is short expiry times. A token’s payload is readable by anyone who holds it, so never put passwords, secrets or sensitive personal data inside one. And the security of an HS256 token rests entirely on the secret: if the secret leaks, anyone can forge tokens, so secrets must be long, random and stored safely on the server, never shipped to browsers in production code.
Common mistakes to avoid
The most famous JWT mistake is accepting tokens with alg “none”, meaning no signature at all. Some libraries historically allowed this, and attackers used it to forge tokens. Always require the expected algorithm. Another mistake is using a weak secret like “secret” or “password”, which can be brute-forced offline, because an attacker with a token can test candidate secrets until the signature matches. A third mistake is trusting the payload without verifying the signature, which is like trusting a letter because the envelope looks right.
If you are learning JWTs, this tool is a safe place to experiment: generate tokens, change one character of the payload, and watch verification fail. That single experiment teaches the core idea better than any diagram. And remember, your secret never leaves this page. The signing happens in your browser, and nothing is sent to any server.
Common questions
Is a JWT encrypted? No, unless you use JWE, the encrypted variant. A plain JWT’s payload is just base64, readable by anyone. Can I use this tool’s tokens in production? Only as examples: production secrets must live on your server, never in a browser tool. Why HS256 and not RS256? HS256 uses one shared secret and is simpler; RS256 uses a private key to sign and a public key to verify, which suits systems where many verifiers must not be able to forge tokens.