JWT Signer
Free JWT signer — mint a signed JSON Web Token with HS256/384/512, RS256, PS256, ES256, ES256K or EdDSA, with custom claims and extra header fields. Signed locally in WebAssembly; your key never leaves the page.
Extra header fields — optional
Runs entirely in your browser — nothing you enter is uploaded or stored.
Minting a JSON Web Token
A JWT is three base64url segments: a header naming the algorithm, a payload of claims, and a signature over the first two. Signing is what makes the claims worth anything — without it, the payload is a form field that anyone can rewrite.
Symmetric or asymmetric
With HS*, the key that verifies is the key that signs. That is fine inside one service and wrong the moment a second party needs to check tokens, because the ability to verify becomes the ability to issue. RS*, PS*, ES* andEdDSA split those: you publish the public key, and only you can mint.
The claims that matter
exp is the one people omit and regret — a token without an expiry is valid until the key rotates. iat lets a server reject implausibly old tokens,aud stops a token issued for one service being replayed at another, andjti gives you something to revoke. None of them are enforced by the format; they are enforced by the verifier, and only if it checks.
Verifying what you made
Paste the result into theJWT decoder and verifier with the matching key to confirm it round-trips.
Frequently asked questions
Which algorithm should I choose?
HS256 when the same party signs and verifies — a session token your own API issues and checks. Use an asymmetric algorithm (RS256, ES256, EdDSA) when someone else must verify without being able to mint tokens, which is the case for any public API or federated identity. The distinction is not about strength; it is about who is allowed to issue.
What key do I paste?
For HS256/384/512, the shared secret as text — and it should be a high-entropy random string, not a memorable phrase, because an offline attack on a captured token is a straightforward brute force. For RS/PS/ES/EdDSA, the signing private key in PKCS#8 PEM.
Why is there no "none" algorithm?
Because it is the classic JWT vulnerability rather than a feature. A token with alg: none has no signature, and libraries that honoured the header's algorithm choice would accept one — letting an attacker strip the signature and be believed. The engine does not implement it, and a verifier should reject it outright rather than treat it as an option.
Should I put sensitive data in the payload?
No. A JWT is signed, not encrypted — the payload is base64url, readable by anyone holding the token. Sign claims that are safe to disclose, and keep anything private on the server behind an opaque identifier.