JWT generator (HS256, HS384, HS512)
Create a JSON Web Token signed with HS256, HS384 or HS512 using your secret key, with automatic iat and exp dates. Signing happens in your browser.
- Free
- No sign-up
- No file uploaded
- Windows, Mac, Android, iPhone
Loading the tool…
About this tool
Write the token payload in JSON, choose the algorithm and secret key: the signed JWT appears instantly, with issued-at and expiry dates calculated for you. Handy for testing a protected API, without installing a library or handing your key to a website.
When to use it
Testing a protected API
Your API checks HS256 tokens? Generate one with the same key as your development environment, the sub and roles you need, then send it in the Authorization: Bearer header from Postman, curl or your browser.
Reproducing an edge case
An expired token, a missing role, an unexpected audience: change the payload and duration to check your server rejects what it should.
Learning how a JWT works
Watching the header, payload and signature change live, in colour, helps you understand that a JWT is only encoded and signed, not encrypted.
How to use
- Choose the algorithm and write the JSON payload.
- Enter or generate a secret key.
- Copy the signed token.
How it works
The header (alg and typ fields) and the payload are serialised as JSON then Base64URL-encoded. The signature is an HMAC computed over “header.payload” with the secret key and the hash function of the chosen algorithm (SHA-256, SHA-384 or SHA-512), using Web Crypto, the browser's native implementation.
If you enter a duration (15m, 1h, 7d), the exp field is added with the expiry date in Unix seconds; iat gets the current date. The resulting token is identical to the one jsonwebtoken (Node.js), PyJWT or firebase/php-jwt would produce with the same key.
Tips for best results
- Use a random key of at least 32 bytes for HS256: the “Generate a key” button creates one.
- Never put a password or sensitive data in the payload: anyone can read it.
- Don't use the production key for tests: generate a key per environment.
- Keep access tokens short-lived (5 to 15 minutes) and use refresh tokens to extend sessions.
- To sign with a private key (RS256, ES256), use a server-side library: the private key should not travel.
Common problems and fixes
My server rejects the token
Check the key is exactly the same (no trailing space) and the server expects the same algorithm. Some servers expect a Base64-encoded key: decode it first.
The token is already expired
The server's clock and your device's may differ, or the duration is too short. Lengthen the duration or leave it empty.
“The payload must be an object”
A JWT payload is always a JSON object in curly braces, not an array or a bare value.
Frequently asked questions
Is my secret key sent anywhere?
No. The signature is computed by Web Crypto in your browser; neither the key nor the payload leaves your device.
Why only HS256, HS384 and HS512?
These are the shared-secret algorithms. RS256 and ES256 require a private key that is best never pasted into a web page.
Is the token encrypted?
No. A signed JWT is only Base64URL-encoded: anyone can read its payload. The signature only guarantees it has not been altered.
How do I verify the token I created?
Open the Zanakit JWT decoder, paste the token and the same key: the signature should show as valid.
Related searches
Still stuck?
Ask on the forum: the category, the tool, your device sheet and the test result will be filled in for you.