JWT Encoder
Build and sign a JSON Web Token (HS256/384/512) from a payload and secret. HMAC signing runs in your browser with Web Crypto — the secret never leaves your device.
About this tool
A JSON Web Token is three base64url segments joined by dots:
header.payload.signature. The header names the signing
algorithm, the payload carries your claims, and the signature is a keyed
hash of the first two parts. This tool assembles all three: choose an HMAC
algorithm, write your payload as JSON, supply the secret, and the signed
token is produced live as you type.
Signing happens entirely in the browser through the
Web Crypto API. Your secret is imported as an HMAC key
and used to sign the header.payload string with SHA-256, -384,
or -512 depending on the algorithm. Nothing is transmitted, which makes it
safe for quickly minting a test token during local development without
reaching for a library or a backend.
Two things worth remembering about JWTs: the payload is encoded, not encrypted, so never put secrets in claims — anyone with the token can read them. And the signature only proves integrity against whoever holds the secret, so HMAC tokens are best for a single service signing and verifying its own tokens. For cross-party scenarios you generally want an asymmetric algorithm instead. Verify anything you build here with the companion JWT Decoder.
Frequently asked questions
Which algorithms are supported?
The HMAC family — HS256, HS384, and HS512 — which sign with a shared secret. Asymmetric algorithms (RS256, ES256) require a private/public key pair and are not generated here. The header’s alg field is set automatically from your choice.
Is my secret safe to type here?
Yes. Signing uses the browser’s Web Crypto API (SubtleCrypto HMAC); the secret and payload stay in memory on your device and are never sent anywhere. That said, treat any real production secret carefully and avoid pasting it on a shared machine.
How do I verify the token I generated?
Paste it into the JWT Decoder to inspect the header and payload, or verify the signature in your own service with the same secret and algorithm. A token signed with HS256 and secret X only verifies against that exact secret.
Why does my decoder say the signature is invalid?
The verifying side must use the identical secret and algorithm, and must sign the exact base64url header and payload. A trailing newline in the secret, a different alg, or re-ordered JSON keys will all change the signature.
Should I put sensitive data in the payload?
No. A JWT payload is only base64url-encoded, not encrypted — anyone holding the token can read it. The signature proves the token was not tampered with; it does not hide the contents. Keep secrets out of claims.