JWT generator (HS256)

Security tools

Generate signed HS256 JWTs from custom header and payload JSON locally.

Updated May 30, 2026

JWT input

JWT output

Quick start

How to generate HS256 JWT

Provide header/payload JSON and shared secret to sign token.

Step 1

Edit claims

Adjust header and payload JSON.
Step 2

Set secret

Provide HS256 secret key.
Step 3

Generate token

Copy signed JWT for testing.

In-depth guide

Generating HS256 JSON Web Tokens for testing and debugging

A JSON Web Token (JWT) is a compact, signed bundle of claims used for stateless authentication and authorisation. This tool builds HS256 tokens — signed with a shared secret using HMAC-SHA256 — entirely in your browser, so you can craft test tokens for an API without standing up an auth server.

The three parts of a JWT

A JWT is three Base64URL segments joined by dots: header.payload.signature. The header names the algorithm (HS256), the payload holds your claims (such as sub, exp and any custom data), and the signature is an HMAC over the first two parts using your secret. The header and payload are only encoded, not encrypted — anyone can read them — so never put secrets in the payload.

How to use this tool

Edit the payload claims — set sub, add roles, and include an exp expiry if your API checks it.
Enter the shared secret your API uses to verify HS256 tokens.
Copy the signed token and send it as Authorization: Bearer <token>.

HS256 vs RS256, and when to use each

HS256 uses one shared secret for both signing and verifying — simple, and ideal when the same party does both, or for local testing like this. When many independent services must verify tokens without being able to mint them, switch to RS256 / ES256, where a private key signs and a public key verifies.

Security and privacy

Treat the signing secret like a production password. A leaked HS256 secret lets anyone forge valid tokens for any user.

Always set an expiry (exp) so a stolen token stops working; short lifetimes plus refresh tokens are safer than long-lived JWTs.
Use this for testing and debugging, not to issue real production tokens from frontend code.
Privacy: signing happens locally via WebCrypto HMAC; the payload and secret are never uploaded.

Common pitfalls

Check the result before replacing the original input.
Watch for unit, format, encoding, and browser memory limits on large inputs.
Keep a copy of important source material until the output is verified.

Frequently asked questions

Which signing algorithm is supported?

HS256 — HMAC-SHA256 with a shared secret — signed locally in your browser using WebCrypto.

Are the header and payload encrypted?

No. They are Base64URL-encoded, not encrypted, so anyone can read them. Never put secrets or sensitive data in the payload.

How do I send the token to an API?

Pass it in the Authorization header as a bearer token: Authorization: Bearer <token>.

When should I use RS256 instead of HS256?

Use RS256 or ES256 when many services must verify tokens without being able to mint them: a private key signs and a public key verifies. HS256 shares one secret for both.

Why should I set an exp claim?

An expiry limits the damage if a token leaks. Short-lived tokens plus refresh tokens are safer than long-lived JWTs.

Does the payload or secret leave the browser?

No. Token signing happens locally via WebCrypto HMAC; nothing is uploaded.

Keep exploring