Skip to content
ToolFarmToolFarm
Developer

JWT Generator

Sign a JSON Web Token with HS256, HS384 or HS512. The secret never leaves your browser.

3 min read

What this tool does

Write the claims you want, enter a signing secret, and get a complete signed token. It is the counterpart to the JWT decoder: that one reads tokens, this one makes them, which is what you need when testing an endpoint that expects particular claims. Signing happens in your browser using the built-in Web Crypto, so the secret is never sent anywhere. Nothing is added to your payload behind your back: many generators quietly insert an issued-at timestamp, which means the same inputs give a different token every second and a claim you never wrote turns up in the decoded output. Here the payload is exactly what you typed, so the same inputs always produce the same token.

What you can use it for

  • Create a test token with specific claims for an endpoint you are building.
  • Reproduce a token that a client reported as failing.
  • Check that your backend rejects a token signed with the wrong secret.
  • Experiment with claims and see what the decoder makes of them.

How to use it

  1. Choose the algorithm your service expects, usually HS256.
  2. Write the payload as a JSON object with the claims you want.
  3. Enter the signing secret.
  4. Copy the token.

Everything runs inside your browser. No file is uploaded to any server. See more tools in this field.

Developer

Frequently asked questions

Is my secret sent anywhere?

No. The signing happens inside your browser tab using the Web Crypto built into it, and nothing is transmitted. That said, please use a test secret rather than a production one: a real signing secret should not be pasted into any web page, however it behaves, because that is a habit worth keeping absolute.

Why only HS256, HS384 and HS512?

Those sign with a shared secret. The RS and ES algorithms sign with a private key, and a tool that invites you to paste a production private key into a web page is a bad idea no matter how carefully it is built. Testing secrets are a different level of risk, so the HMAC family is offered and the key-based ones are not.

Why does it not add iat or exp automatically?

Because you did not ask for them. Injecting a timestamp makes the same inputs produce a different token every second and puts a claim in the payload that you never wrote, which is confusing when you decode it. If you want them, add them to the payload yourself as Unix timestamps, which the timestamp converter can give you.

Why does my token get rejected?

The usual causes are a secret that does not match the one the server verifies with, an algorithm the server does not accept, or a missing claim such as an audience or issuer that it requires. Paste the token into the JWT decoder to see exactly what you produced before looking further.