JWT Encoder

A fast, private JWT signer that turns a header, a payload, and a shared secret into a spec-compliant JSON Web Token. Signing runs 100% in your browser via the Web Crypto API. Your secret never leaves your machine, and no bytes are uploaded anywhere.

Why another JWT encoder?

Because most of the ones that rank for "JWT encoder" are happy to ship your secret to a server the moment you paste it. That's convenient for them — they get a free stream of leaked credentials — and catastrophic for you. Shared secrets are the entire point of the HMAC family; whoever holds the secret can forge any token they want for the lifetime of that key. Pasting one into a random web tool that happens to top the Google results is strictly worse than pasting a password there: one leaked HS256 secret unlocks every JWT your service has ever minted with that key, for as long as rotation hasn't happened yet.

This tool runs the entire signing pipeline client-side. TextEncoder serialises the JSON segments to UTF-8, crypto.subtle.importKey("raw", …, { name: "HMAC", hash: "SHA-256" }, …) wraps your secret as a non-exportable CryptoKey, crypto.subtle.sign computes the HMAC, and a few lines of base64url arithmetic emit the compact JWS form. There is no network call in the signing path, no analytics hook on the secret input, and no third-party script in the chain between your clipboard and the encoded token.

What it does

• HS256 / HS384 / HS512 signing. All three HMAC variants from RFC 7518 §3.2, implemented via Web Crypto so the hash primitive is the one the platform already trusts for TLS.
• Spec-compliant base64url encoding. Both segments are JSON-serialised with no whitespace before encoding — this is a frequent source of subtle signature mismatches when an implementation pretty-prints the JSON and then hashes the pretty form. The = padding is stripped and +// are replaced with -/_ per RFC 7515 §3.
• Live JSON validation. Header and payload editors flag syntax errors inline as you type, without blocking the rest of the UI.
• Color-coded token display. The encoded token is rendered with the same three-color convention jwt.io popularised — red for the header segment, purple for the payload, and blue for the signature — so you can always tell at a glance which byte is which.
• Automatic alg sync. Switch the algorithm dropdown and the header's alg field follows along, unless you've manually edited the header to something different (in which case you're in the driver's seat).
• Claim inspector. A small side panel surfaces the common registered claims (iss, sub, aud, iat, exp) with relative-time chips — "issued 2m ago", "expires in 45m" — so the token stays readable as you tweak the payload.
• Shareable state. The Share button copies a URL that restores the algorithm + header + payload for a teammate. The secret is never stored in the URL fragment.

Privacy-first, offline-capable

After the first visit the entire page is cached, so the encoder works offline — useful at airports, in customer datacenters, on restricted networks that block jwt.io outright. Open the browser devtools Network tab while you sign a token and you'll see exactly zero outbound requests from the signing interaction itself.

The secret input is a standard <input type="password"> with a show/hide toggle, so shoulder surfing is at least a known risk rather than a surprise. The shared-state URL intentionally omits the secret. Analytics never see the secret, never see the payload, and never see the token.

What this tool deliberately doesn't do

• Asymmetric signing (RS256, PS256, ES256, EdDSA). These require PEM or JWK private-key import, which we want to build with care rather than ship as a checkbox. Use a server-side signer with a properly-stored private key until we ship the asymmetric variant.
• Key generation. The encoder takes a secret you already have. For generating new HMAC secrets use the Password Generator (pick 256 bits of entropy for HS256, 384 for HS384, 512 for HS512).
• Claim inference. We do not auto-inject iat, exp, or jti — your payload is signed exactly as you wrote it. The UI warns about missing registered claims, but the transform stays unopinionated.
• Token verification. Signing and verification are different trust decisions. Use the sibling JWT Decoder to inspect an existing token's claims; for actual verification use a server-side library (jose, jsonwebtoken, PyJWT) with the issuer's key.

Related tools

• JWT Decoder — the direct counterpart. Paste a token, inspect its three parts, watch the expiry countdown. The decoder is what your consumers run; this encoder is what the issuer runs.
• SHA-256 Hash — if you are debugging a signing mismatch and want to confirm that the pre-signing bytes are what you think they are, hash the header.payload string here and compare.
• Base64 Encode / Decode — peel individual segments by hand when you want to see exactly what the raw JSON bytes look like before base64url.

When you need a signed JWT in the fewest keystrokes, this is the shortest private path: paste, pick, sign, copy.