JWT Generator & Client-Side Signer

Overview

Signs a JWT with HS256 in your browser from raw header and payload JSON that you edit directly, using Web Crypto HMAC-SHA-256. Unlike a form-driven builder, you control the exact JSON - claim order and all - and the finished three-part token re-signs live as you type. The secret stays on the page.

How It Works

The tool opens with a standard header ({"alg":"HS256","typ":"JWT"}) and a payload containing sub, name, role, iat set to the current Unix second and exp one day out. Edit either JSON box and the token below re-signs on every change. Enter your secret, then press Copy JWT when the token looks right. Invalid JSON or a signing failure surfaces as an error line instead of a stale token, so a half-edited payload never masquerades as output.

Step-by-Step Usage Guide

1. Paste or edit the header JSON. Keep alg set to HS256 unless you are deliberately probing how a verifier reacts to odd headers.
2. Edit the payload. iat and exp are pre-filled as Unix seconds; change or add claims freely, remembering the verifier will read exactly these bytes.
3. Enter the secret your API checks against. For testing, any string works; do not paste a production signing secret into a browser tool.
4. Copy the signed token and send it in an Authorization: Bearer header, or run it through the site's brute-checker to confirm the secret is not in the obvious dictionary.

Technical Specifications & Standards

The pipeline is the one RFC 7519 and RFC 7515 define: base64url the header, base64url the payload, join them with a dot, HMAC-SHA-256 that string with your secret, base64url the MAC, and append it. Base64url differs from RFC 4648 base64 in swapping + and / for - and _ and dropping padding, which is what makes JWTs safe in URLs and headers. Because the header and payload are whatever JSON you typed, you can mint tokens with unusual headers, nested claims or reordered keys - useful when debugging a strict verifier - but note the base64url step runs on the JSON.stringify output through btoa, and btoa throws on characters outside Latin-1, so non-ASCII claim values must be escaped (\uXXXX) or the tool reports the error. This tool differs from the site's JWT Generator deliberately: that one builds claims from form fields, this one signs exactly the JSON you paste, which is what you want when reproducing a byte-level signature mismatch. HS256 is symmetric: the secret that signs also verifies, so anyone holding it can mint arbitrary tokens.

Targeted Use Cases

• Reproducing a signature-verification failure byte for byte, by signing exactly the header and payload your server received.
• Minting test tokens with custom claims - roles, scopes, tenant ids - for integration tests without standing up a full auth flow.
• Comparing how two JWT libraries handle claim ordering or extra header fields, since the signature covers the exact serialized bytes.
• Teaching the JWS compact serialization: the live re-signing makes the relationship between the three segments visible as you edit.

Notes & Gotchas

• Never sign with a production secret here. HS256 is symmetric, and the secret is typed into a text field in a browser; use a development key.
• Keep timestamps in seconds. iat and exp are Unix seconds in the spec; a milliseconds value produces an expiry thousands of years out.
• Escape non-ASCII characters in claims. btoa, which the base64url step is built on, throws on characters above Latin-1, and the tool will show that error.
• Assume the token is readable. Header and payload are encoding, not encryption - anyone holding the token can decode both.

Frequently Asked Questions