Treated as a UTF-8 string. Use a strong, random secret in production.
alg and typ are set automatically.
—
Signed locally with Web Crypto (HMAC). Nothing leaves your browser.
About JWT Encoder
JWT Encoder builds a signed JSON Web Token from a header, a payload, and a signing secret. Pick the algorithm — HS256 / HS384 / HS512 — fill in the claim payload, and the tool emits the dot-separated `header.payload.signature` token, signed with the browser's Web Crypto HMAC primitive.
This is the build half of the JWT toolkit; JWT Decoder is the inspect half. Reach for it when you need a token to test an authentication flow against your API, generate a short-lived token for local development, or hand-craft a fixture for an integration test. Every JWT you sign carries a real signature — never paste a production secret into a tool you do not trust. This one runs entirely in your browser, but the policy still applies: prefer test secrets and rotate-able keys for any tool you are evaluating.
Examples
header: { "alg": "HS256" }
payload: { "sub": "1234", "name": "Ada", "exp": 1715000000 }
secret: my-test-secreteyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6IkFkYSIsImV4cCI6MTcxNTAwMDAwMH0.<signature>HS256 with a symmetric secret. The output is a complete, verifiable JWT.
Frequently asked questions
Should I paste my production secret here?
No. Use a test secret or a locally-generated key, even though the tool runs entirely in your browser. Treat any browser-based signing tool the same way you treat a paste into a terminal — fine for non-production secrets, never for production credentials.
How is this different from JWT Decoder?
Encoder takes header + payload + key and produces a signed token. Decoder takes a signed token and surfaces the header and payload (without verifying the signature). Encoder is for building tokens; Decoder is for inspecting them.
Which algorithm should I pick?
For server-to-server with a shared secret: HS256 is fine. For tokens issued by a service to clients that should not be able to forge new ones: prefer an asymmetric algorithm (RS256 or ES256) implemented in your backend and keep the private key on the issuer. Avoid `none` (unsigned tokens) — the algorithm-confusion attack class makes it dangerous.
Can I include arbitrary claims?
Yes. The payload is any JSON object. The standard claims (`iss`, `sub`, `aud`, `exp`, `nbf`, `iat`, `jti`) have well-defined meanings; everything else is custom and your verifier decides how to interpret it.