JWT Generator

about this tool

Build the payload, pick a key, sign

A JSON Web Token is three Base64URL segments joined by dots: a header saying how it was signed, a payload of claims, and a signature over the first two. This page builds all three.

Put your claims in the payload box. iat and exp are added when you sign, unless you have already set them yourself — a value you typed is never quietly overwritten.

What the signature actually covers

The signing input is the encoded header and the encoded payload, joined by a dot. That is the specification's one piece of real cleverness: the signature covers exactly the bytes the reader will see, so re-encoding the JSON later cannot change what was signed, even if the key order or the whitespace differs.

It also means the header is part of the signature. If the header box says one algorithm and the chooser says another, the page refuses rather than picking for you.

Secrets and private keys

The HMAC algorithms — HS256, HS384, HS512 — sign with a shared secret, the same string the verifier holds.

Everything else signs with the private half of a key pair: paste a PKCS#8 PEM, the block beginning BEGIN PRIVATE KEY, or a JWK containing d. A public key is refused with the reason, because that is the mistake people actually make here. So is BEGIN RSA PRIVATE KEY — that is the older PKCS#1 format and browsers cannot read it, so the page gives you the openssl command that converts it.

Nothing leaves your browser. Even so, a production private key pasted into any web page is a habit worth not having, and the page says so where you paste it. Generate a test pair with the key pair generator if you need one.

No unsigned tokens

There is no none option. An algorithm of none is the oldest JWT attack there is — strip the signature, set alg to none, and a careless verifier accepts anything — and a tool that produces them in one click is a tool that helps the wrong person.

Checked against the decoder

The two tools share one table of what each algorithm is and how to import a key for it, so they cannot drift apart about what ES512 means. The tests go further: for each family they generate a real key pair, sign a token here, and verify it with the JWT decoder's own code.

questions

Is my key sent anywhere?

No. Signing happens in this page with the browser’s own WebCrypto, and nothing is uploaded or stored. That said, pasting a production private key into any web page is a habit worth not having, however honest the page. Use a test key.

Why does it want a private key and the decoder only wants a public one?

That is the whole point of the asymmetric algorithms. The private half makes signatures and the public half checks them, so signing here needs the private key while verifying next door needs only the public one.

It says my key is PKCS#1 and will not import it.

Browsers can only read PKCS#8 for private keys. A key whose PEM starts BEGIN RSA PRIVATE KEY is the older PKCS#1 format; convert it with openssl pkcs8 -topk8 -nocrypt -in key.pem -out key-pkcs8.pem and paste the result.

What are iat and exp, and do I need them?

Both are seconds since 1970. iat is when the token was made and exp is when it stops being valid. They are added for you when you sign, unless your payload already sets them, in which case your value is kept. You can turn exp off, but most verifiers reject a token that never expires.

Can it make an unsigned token?

No. An alg of none is the oldest JWT attack there is, and a tool that makes them with one click is a tool that helps the wrong person. If you need one for a test, you can build it by hand.

Will the decoder here accept what this makes?

Yes, and that is checked rather than assumed: the tests sign a token with a freshly generated key pair for each algorithm family and then verify it with the decoder’s own code.