JWT Builder
Processed Client SideBuild and sign a JSON Web Token with a custom payload using HS256, HS384, or HS512. Signing happens entirely in your browser with the Web Crypto API.
Bookmark this tool now — skip the search next time you need it.
About JWT Builder
This tool runs entirely in your browser. Whatever you paste is processed on your own device and is never uploaded, logged, or sent to any server.
Build a JSON Web Token from a custom payload and sign it with an HMAC secret, entirely in your browser. It is the counterpart to decoding one: useful for producing a test token with the exact claims you want, reproducing a bug that only happens for a particular role, or checking that your backend accepts and rejects the tokens it should. You supply the payload as JSON and a signing secret, choose HS256, HS384, or HS512, and get back a complete three-segment token. Signing uses the Web Crypto API, so the secret never leaves the page. The finished token is printed with each of its three segments in a different colour against a legend, which makes the structure obvious and makes a truncated or mis-pasted token easy to spot.
Key features
- Three HMAC algorithms: HS256, HS384, and HS512
- Fully editable JSON payload with syntax highlighting
- Header generated automatically to match the algorithm you chose
- Correct base64url encoding of all three segments, without padding
- Signed with the Web Crypto API
- JSON errors in the payload reported before signing rather than producing a broken token
- One-click copy of the finished token
- Token displayed with header, payload, and signature colour-coded against a legend, so the three-segment structure is visible at a glance
- Starts from a realistic sample payload with sub, name, and iat, so there is something to sign before you have written anything
- Runs entirely in your browser — your signing secret is never transmitted
How to use it
- Choose the signing algorithm your backend expects.
- Enter the signing secret.
- Edit the payload to hold the claims you need, including exp as a UNIX timestamp.
- Build the token and copy it.
Tips & common mistakes
- exp and iat are in seconds since the epoch, not milliseconds. A token that expires immediately or in the year 55000 is almost always this mistake.
- Build tokens for testing, not for production auth. A real token should be issued by your identity provider, which owns the secret and the claim policy.
- The payload is only encoded, never encrypted. Anyone holding the token can read every claim, so never put anything private in it.
- The secret must match your backend exactly. Signature verification failures are usually a whitespace or encoding difference in the key rather than an algorithm mismatch.
- HS256 is symmetric — the same secret signs and verifies. If different parties must verify without being able to mint tokens, you need RS256 and a key pair instead.
- Use a genuinely long random secret. HMAC security depends on it, and a short dictionary word can be brute-forced offline against a captured token.
- Paste the result into the JWT Decoder to confirm the claims and expiry decode as you intended.
- HS384 and HS512 are not more secure than HS256 in any way that matters here — they produce a longer signature, and therefore a longer token. Match whatever your backend is configured for rather than picking the biggest number.
- Base64url is not plain base64: it uses - and _ in place of + and /, and drops the = padding. A token that fails to verify after being passed through a system that re-encoded it has usually been converted to standard base64 somewhere along the way.