JWT Builder
Sign HS256, HS384, or HS512 JWTs in your browser using the Web Crypto API. The signing key never leaves your machine — because the key is the credential.
HS256 is the default for almost every JWT. HS384/HS512 are larger and rarely needed unless your spec demands them.
⚠ Your secret never leaves your browser. ToolChop signs with crypto.subtle.sign locally. Still — never paste a production server secret into any tool you have not audited yourself.
alg is forced to the selected algorithm; other fields pass through.
Common claims: sub, iat, exp, iss, aud.
Enter a secret to sign and produce the JWT. The signing runs entirely in your browser.
How to build a signed JWT online
Pick an algorithm (HS256 is the default and covers almost every JWT you will encounter). Edit the Header and Payload boxes — both are valid JSON, and the sample is pre-filled with the canonical claims (sub, iat, exp). Paste your HMAC signing secret. ToolChop signs using crypto.subtle.sign — the same Web Crypto primitive your backend libraries use under the hood — and produces the JWT instantly. Click Open in JWT Decoder to round-trip verify.
Why a local JWT builder matters more than for any other tool
The HMAC signing secret is the credential. Anyone who has it can forge tokens that look authentic to your server, and the consequence touches every user of that server. Pasting a server JWT secret into a tool whose data path you have not audited end-to-end is equivalent to handing that party master keys to your auth system. ToolChop signs entirely in your browser — the secret stays on your machine, and you can verify it with DevTools → Network.
Algorithm safety
ToolChop forces the header's alg field to match the algorithm you selected. Mismatched alg headers are a known JWT vulnerability — an attacker can sometimes downgrade or replace an algorithm and trick a poorly-written verifier. Forcing alignment in the builder means the token you produce is internally consistent.
What you can do
- HS256, HS384, HS512 signing (HMAC-SHA family)
- Live header and payload editing with JSON validation
- Pre-filled sample with current-time
iatand +1hexp - One-click deep link to the JWT Decoder to verify the round-trip
- Browser-only signing via
crypto.subtle.sign
When to use which algorithm
- HS256 — the default. Strong enough for almost every JWT use case. Smallest signature.
- HS384 — uncommon. Some EU government profiles and a few enterprise specs require it.
- HS512 — strongest HMAC. Use only if your spec specifically requires it; bigger signature, no practical security gain for typical web auth.
Frequently asked questions
How do I sign a JWT online for free?
Pick an algorithm (HS256 by default). Edit the Header and Payload JSON boxes. Paste your HMAC secret. ToolChop signs the JWT in your browser using the Web Crypto API and shows the resulting token in the green panel. Copy it with one click, or open it in our JWT Decoder to verify the round-trip. No account, no upload, no daily limit.
Does ToolChop send my HMAC secret to a server?
No. The signing key, the header, and the payload are all kept entirely in your browser. ToolChop signs the JWT using crypto.subtle.sign from the Web Crypto API — the same primitive your backend libraries use under the hood. You can verify in DevTools → Network that no request fires when you type the secret.
Why is the privacy story for a JWT builder the most important one?
Because the signing secret IS the credential. Any party that knows the secret can forge tokens that look authentic to your server, and the consequences span every user. Pasting a server JWT secret into a tool that POSTs it back to its API — even for analytics or 'history' — is equivalent to handing that party master keys to your auth system. ToolChop signs entirely in your browser so the secret stays in exactly one place: your machine.
Should I really paste a real production secret?
Be very cautious. ToolChop runs entirely locally and you can verify it with DevTools, but the prudent practice is to never paste production secrets into any tool you have not audited end-to-end. For real production work, use the JWT library in your codebase. ToolChop is best for: signing tokens with a test/dev secret, prototyping a new claim shape, verifying that an existing library produces the same byte sequence, learning how JWT signing works.
What algorithms are supported?
HS256, HS384, and HS512 — the HMAC-SHA family of symmetric JWT algorithms. RS256 / ES256 / EdDSA (asymmetric) are not supported here because they need a private key in PEM/JWK format and the browser's Web Crypto handling of those is more involved — for those, use your backend library.
Why is the 'alg' header forced to match my algorithm choice?
Because mismatched alg headers are a known JWT vulnerability (CVE-class). If the header says alg: none but the implementation expects HS256, or vice versa, an attacker can forge tokens. ToolChop overwrites the header's alg to match the algorithm you picked so the resulting token is internally consistent.
What claims should I include in the payload?
The canonical claims (RFC 7519): sub (subject — the user ID), iss (issuer), aud (audience), iat (issued-at UNIX timestamp), exp (expiration UNIX timestamp), nbf (not-before timestamp), jti (unique token ID). The sample payload prefills iat and exp at the current time and +1 hour — adjust as needed. Add your own custom claims (roles, scopes, plan) alongside.
How is the timestamp in the sample payload generated?
iat is set to the current UNIX timestamp at page load; exp is iat + 3600 seconds (1 hour). These are starting points — edit them to whatever your real token needs.
Does ToolChop validate the JSON before signing?
Yes. If the Header or Payload boxes contain invalid JSON, ToolChop shows a clear error message with the parse failure reason. The signing only fires when both parse successfully and a secret is present.
Can I verify the token I built?
Yes. Click Open in JWT Decoder to load the token into our decoder — it shows the header and payload broken out, and humanizes the iat/exp timestamps. The decoder cannot verify the signature (verification requires the secret, which should stay server-side), but it confirms the encoding is correct.
What format does the signature use?
Base64url (RFC 4648 §5) — the JWT spec mandates it. Standard base64 + and / are replaced with - and _, and trailing = padding is stripped. ToolChop applies that transformation automatically.
Why use ToolChop instead of an online JWT builder?
Because most online JWT builders run server-side, which means the signing happens on someone else's server with your HMAC secret. Even if they claim 'we don't log', the data path passed through their infrastructure. ToolChop signs entirely in your browser with crypto.subtle.sign — there is no server involved, and you can verify it with DevTools → Network.