Overview
Generate and sign JWTs in your browser
A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties. It is made of three parts joined by dots: a header, a payload, and a signature. The header and payload are JSON objects encoded with Base64URL, and the signature proves the token was created by someone who holds the secret key.
ToolHub JWT Generator builds a signed token from your payload and secret using HMAC. Pick HS256, HS384, or HS512, paste your claims, set a secret, and copy the token. Everything happens in your browser, so your secret never leaves your machine.
Step-by-step
How to generate a JWT
- 1
Choose an algorithm
HS256 is the most common. HS384 and HS512 use a larger hash if you need a longer signature. - 2
Enter your payload
Type or paste a JSON object of claims, such as a subject, name, and issued-at timestamp. The token updates as you type. - 3
Set a secret and copy
Add the shared secret used to sign the token, then click copy to grab the fullheader.payload.signaturestring.
Background
What the three parts mean
The first segment is the header, which declares the signing algorithm and token type. The second is the payload, which carries your claims. The third is the signature, computed over the first two segments using your secret. A verifier recomputes the signature and compares it to detect tampering.
What does HS256 mean?
HS256 means HMAC using SHA-256. HMAC mixes your message with a secret key so that only someone who knows the key can produce a matching signature. HS384 and HS512 are the same idea with SHA-384 and SHA-512.
Encoding is not encryption
The header and payload are only Base64URL encoded, not encrypted. Anyone can decode and read them. Never put passwords or other secrets in the payload. The signature protects against tampering, not against reading.
Use cases
When to use a JWT generator
Testing API authentication
Build a valid signed token to call a protected endpoint while developing or debugging.
Learning how JWTs work
Watch the token change as you edit claims and the secret to understand each segment.
Mocking auth in local dev
Create tokens with custom claims so your front end can exercise role-based flows offline.
Reproducing a signature
Confirm that a given payload and secret produce the exact signature your service expects.
Seeding integration tests
Generate deterministic tokens for fixtures that your test suite can rely on.
Demonstrating tamper detection
Show how changing one character of the payload breaks the signature and invalidates the token.
Tips and best practices
- Use a long, random secret. Short or guessable secrets make HMAC tokens easy to forge.
- Keep the payload small. JWTs travel in headers, and large tokens add overhead to every request.
- Add an exp claim in real systems so tokens expire instead of living forever.
- Never store sensitive data in the payload. It is readable by anyone who holds the token.
- HS256 is fine for most cases. Step up to HS384 or HS512 only when a policy requires it.
Common questions
Is the secret sent anywhere?
No. Signing happens locally with the Web Crypto API. Your payload and secret stay in the browser and are never uploaded.
Why does my token change when I edit the payload?
The signature is computed over the header and payload. Any change to the payload changes the encoded payload segment, which changes the signature, which changes the whole token.
What is the difference between Base64 and Base64URL?
Base64URL is a variant safe for URLs and headers. It replaces plus with dash, slash with underscore, and drops the padding equals signs. JWTs use Base64URL for all three segments.
Can I verify a token here too?
This tool signs and generates tokens. To verify, recompute the HMAC over the same header and payload with the same secret and compare it to the third segment.
100% private