JWT Encoder (Generate & Sign)
Generate an HMAC-signed JWT (JSON Web Token) from header and payload JSON using HS256, HS384, or HS512 — right in your browser. Nothing, including the secret, is ever sent to a server.
Supported HMAC Signing Algorithms
| Algorithm | Hash Function | Signature Length | Description |
|---|---|---|---|
| HS256 | SHA-256 | 256 bits (32 bytes) | The most widely used default HMAC signature. Standard in many implementations, including OAuth 2.0 and OpenID Connect ID tokens. |
| HS384 | SHA-384 | 384 bits (48 bytes) | A middle-ground option for when you want a longer signature than HS256 for extra security margin. |
| HS512 | SHA-512 | 512 bits (64 bytes) | Has the longest signature length and is typically paired with a sufficiently long, random secret. |
Creating and signing a JWT
This tool assembles a JWT on the spot from header and payload JSON, signing it with HMAC using HS256, HS384 or HS512. Everything you enter, the secret key included, is handled inside the browser alone and is never sent to a server.
**The point most often misunderstood here is that a signature exists to detect tampering and is not encryption.** The header and payload of a JWT are merely Base64URL encoded, so **anyone holding the token can read its contents straight off.** That is why passwords and personal details have no business in a payload. The other point concerns the nature of the key: the HS family works by **having the signing side and the verifying side share the same secret.** If verification is to be delegated elsewhere, you will want a public-key scheme such as RS256 or ES256, which spares you from handing the secret over.
How to create one
- Enter the header JSON It takes the form `{"alg":"HS256","typ":"JWT"}`. Keep it consistent with the algorithm you choose.
- Enter the payload JSON Write whatever claims you need, such as `sub`, `iat` and `exp`. **Keep anything meant to stay secret out of it.**
- Choose the signing algorithm HS256, HS384 and HS512 are available; the number gives the bit length of the hash.
- Supply the secret and take the token The result is a string of three parts joined by dots.
Tips for getting more out of it
- The JWT is signed entirely with your browser's Web Crypto API — the header, payload, and secret are never sent to the toolbase.cc server.
- Switching the signing algorithm (HS256/HS384/HS512) automatically updates the
algfield in the header JSON. Edit the header directly if you want to add other claims likekid. - This tool only supports HMAC (symmetric key) algorithms. If you need a public-key algorithm such as RS256 or ES256, use a server-side library like a Node.js JWT package instead.
- After editing the header or payload, remember to click "Generate JWT" again — otherwise the token shown is still signed from the previous input.
- To check the contents of a JWT you just generated, paste it into the companion JWT Decoder tool to verify the header and payload.
Where it comes in useful
Testing how an API behaves
**Being able to mint a token with any claims you like makes it quick to exercise the branches of an authorisation rule.**
Checking how expiry is handled
Create a token whose `exp` lies in the past and confirm that an expired token is properly turned away.
Preparing tokens for tests
You can produce a token with fixed contents to serve as a fixture in an automated test.
Learning the structure of a JWT
Generating repeatedly while varying the input lets you watch which part of the token each piece ends up in.
JWT terms
- Header
- The first part, stating the algorithm and the type. It carries `alg` and `typ`.
- Payload
- The second part, holding the claims. **It is only Base64URL encoded and is not encrypted in any way.**
- Signature
- The third part, computed from the header and payload with a key. **It serves to detect tampering and does nothing to conceal the contents.**
- Claim
- Each entry within the payload. Standard ones include `sub` for the subject, `iat` for the time of issue and `exp` for the expiry.
- HMAC
- A message authentication scheme using a shared key. **Both the signing side and the verifying side must hold the same secret.**
- Base64URL
- Base64 with its symbols swapped so it can travel in a URL: `+` and `/` become `-` and `_`, and the trailing padding is dropped.
Frequently Asked Questions
alg field's value, another implementation verifying the token may reject it with an error — so make sure the two always match.
Side Note — Why JWT Signing Can Be Done Entirely in the Browser
JWT signing algorithms fall into two broad families: "symmetric key" algorithms (HMAC, i.e. HS256/HS384/HS512), where sender and receiver share the same secret, and "public-key" algorithms (like RS256 and ES256), where a private key signs and a public key verifies. Because the former can be computed entirely with the W3C-standardized Web Crypto API's (SubtleCrypto) crypto.subtle.sign() — with no external library required — this tool deliberately limits itself to HMAC algorithms only.
The security of an HMAC signature depends entirely on how hard the secret is to guess, not on the contents of the header or payload. RFC 7518 (JSON Web Algorithms) recommends a key length of at least 256 bits (32 bytes) for HS256; using a short word or a dictionary string as your secret risks the signature being forged via brute force. In real deployments, you should use a sufficiently long, randomly generated string as your secret.
This tool is a developer utility meant for checking API behavior during development or testing webhook signature-verification logic. The secret you enter is handled only in your browser's memory and never transmitted externally, but the risk from a shared machine or a browser extension harvesting clipboard contents or input isn't zero. We strongly recommend never entering a secret you actually use in production into a tool like this, even just to check it works.