JWT Generator (HS256)

Sign HS256 JSON Web Tokens in your browser with Web Crypto.

Free HS256 JWT generator — enter a JSON payload and a secret, and get a signed JSON Web Token. Signing uses the browser's built-in Web Crypto HMAC-SHA256, so your secret and payload never leave the page. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What algorithm does this use?

It signs with HS256 — HMAC using SHA-256 — via the browser's Web Crypto API. The header is fixed to {"alg":"HS256","typ":"JWT"}.

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:

  1. Header — fixed to {"alg":"HS256","typ":"JWT"} and Base64URL-encoded.
  2. Payload — your JSON claims, Base64URL-encoded.
  3. SignatureHMAC-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:

ClaimMeaningExample value
subSubject (user ID)"user_123"
issIssuer"https://auth.example.com"
audAudience"https://api.example.com"
iatIssued at (Unix seconds)current timestamp
expExpiry (Unix seconds)iat + 3600 for 1 hour
jtiUnique token IDa 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.