JWT Generator
Sign JWTs with HMAC secrets.
About JWT Generator
A JSON Web Token is three pieces of text joined by dots: a header naming the algorithm, a payload carrying claims, and a signature proving the payload was not altered. This generator signs tokens with an HMAC secret using HS256, HS384, or HS512, which is the family most APIs use for session tokens and service-to-service calls. The header and payload are editable as formatted JSON, standard claims such as iat for the issue time and exp for expiry are filled in from your choices, and the signed token appears below the moment you click sign. Because encoding is just base64, a token is readable by anyone who holds it, which is why the signature matters: it proves the payload came from someone holding the secret. Signing runs in your browser, so test secrets stay local.
How to Use JWT Generator
Edit the payload
Replace the sample claims in the right box with your own. Keep sub for the subject, add fields your API expects, and leave iat set to zero so it is filled with the current time at signing.
Choose algorithm and expiry
Pick HS256 unless the service demands otherwise. Set the lifetime from five minutes to one day, or choose Never for a token without an exp claim, which is useful for long-lived machine tokens in tests.
Provide a secret
Type your signing secret or click the dice button for a random 256-bit value. In real use, the secret must be the same one the verifying service holds, otherwise the signature will not validate.
Sign and copy
Click Sign token and the three-part token appears below. Copy it into an Authorization header, a test client, or the JWT Decoder to inspect it.
Why Use JWT Generator: Common Use Cases
Testing an API during development
Generate a token with the claims your endpoint expects, drop it into your HTTP client of choice, and test protected routes without wiring up a full login flow.
Building a service-to-service credential
Sign a token with a long expiry for an internal integration, hand the secret to the other service, and confirm both sides agree before writing it into production config.
Learning how JWT structure works
Change one character of the payload after signing, then decode the token anywhere to see how the signature check fails. Nothing teaches token tampering faster.
Reproducing a production bug locally
Recreate the shape of a problematic token with the same claims and algorithm, so your local API processes it exactly as production would.
JWT Generator Specifications
| Input Formats | Header JSON, Payload JSON, HMAC secret |
|---|---|
| Output Formats | Signed JWT string |
| File Size Limit | No strict limit (dependent on device memory) |
| Processing Engine | 100% Client-side (Runs locally in your browser) |
| Data Retention | Files never leave your device |
| Batch Processing | Single file processing |
Tips for JWT Generator
HS256 is fine for most cases. Use HS384 or HS512 only when a security policy names them, and make sure the verifying side supports the same choice.
An expiry of fifteen minutes matches common access token practice. Long-lived tokens are convenient, but each one is a standing credential you must revoke manually.
Never put a password or a full card number in a payload. Base64 is not encryption; anyone holding the token reads every claim.
Keep registered claim names lowercase:
sub,iss,aud,iat,exp. Custom claim names are free-form, but consistency across services saves headaches.Already have a token and need to read it? The JWT Decoder unpacks the header and payload and shows the expiry in your local time.
Frequently Asked Questions
What is the difference between signing and encrypting?
Signing proves integrity and origin: nobody without the secret could produce a matching signature. Encrypting hides the content. A JWT signed with HS256 is readable by anyone who has it, so treat the payload as public and keep secrets out of it.
How long should my secret be?
At least 256 bits for HS256, which is 32 random bytes or their base64 form. Short secrets such as single words are brute-forceable from a handful of captured tokens. The dice button produces a full-strength value.
Why does my token fail validation on the server?
The usual causes are a different secret on the verifying side, an expired exp claim, or an algorithm mismatch where the server expects RS256 but received HS256. Decode the token and check the claims against what the server requires.
Can this tool sign RS256 tokens with a private key?
Not currently. RSA signing needs key material that browsers handle differently, and HMAC covers the majority of API testing needs. For key-based flows, sign with your existing toolchain.
Are my tokens and secrets stored anywhere?
No. The signing happens in your browser with the Web Crypto API, and nothing is written to storage or sent over the network. Refreshing the page clears everything.
What do iat and exp actually control?
The iat claim records when the token was created, and exp records when it stops being acceptable. Servers compare both against their own clock, so a token minted on a machine with a badly wrong clock can be rejected instantly.