Generate a signed HS256 JWT
Testing an API that expects a Bearer token often means hand-signing a JWT. This
tool builds and signs a JSON Web Token with the HS256 (HMAC-SHA256) algorithm
in your browser: provide a JSON payload and a shared secret, and it emits a
standard header.payload.signature token ready to drop into an
Authorization: Bearer header.
HS256 is a symmetric algorithm — the same secret is used to both sign and verify. It is the most common choice for single-service authentication flows where the issuer and verifier are the same system or share the secret securely.
How it works
A JWT is built from three parts, each step running locally via the Web Crypto API:
- Header — fixed to
{"alg":"HS256","typ":"JWT"}and Base64URL-encoded. - Payload — your JSON claims, Base64URL-encoded.
- Signature —
HMAC-SHA256(header + "." + payload, secret), Base64URL-encoded.
The three parts are joined with dots to produce the final token. Because HS256 is
symmetric, any party that holds my-secret can both produce and verify a token
signed with it — which is why the secret must be kept private to the parties that
need it.
Worked example
A payload of { "sub": "1234", "name": "Sam", "iat": 1700000000, "exp": 1700003600 }
signed with the secret my-secret produces:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiIxMjM0IiwibmFtZSI6IlNhbSIsImlhdCI6MTcwMDAwMDAwMCwiZXhwIjoxNzAwMDAzNjAwfQ
.<HMAC-SHA256 signature>
The first segment decodes to the header {"alg":"HS256","typ":"JWT"}, the second
to your full payload, and the third is the HMAC that any party holding my-secret
can recompute to verify the token has not been tampered with.
What claims to include
Useful claims for testing and development:
| Claim | Meaning | Example value |
|---|---|---|
sub | Subject (user ID) | "user_123" |
iss | Issuer | "https://auth.example.com" |
aud | Audience | "https://api.example.com" |
iat | Issued at (Unix seconds) | current timestamp |
exp | Expiry (Unix seconds) | iat + 3600 for 1 hour |
jti | Unique token ID | a UUID |
For testing a specific endpoint, include the claims your API actually validates.
If your server checks aud, include it in the payload or the token will be rejected.
HS256 vs RS256 — when to use which
HS256 (this tool) — symmetric, one shared secret. Best for single-service auth where the issuer and verifier are the same system. Fast and simple, but the secret must be shared to every service that verifies tokens.
RS256 — asymmetric, private key signs, public key verifies. Best for multi-service environments where you want to publish a public key and let any service verify tokens without knowing the signing secret.
Security notes
The signing uses the browser’s native Web Crypto API — your secret and claims
never leave the page, so it is safe for local development and integration testing.
That said, do not use secrets from production systems in any browser-based tool
on a shared or untrusted machine. For production use, sign tokens server-side
using a cryptographic library (jsonwebtoken in Node.js, PyJWT in Python, etc.)
with secrets loaded from environment variables or a secrets manager.