PEM to JWK Converter

About JWK Generator

A JSON Web Key for a JOSE algorithm, with the public key set to serve alongside it. Choose the alg you will actually write in the token header — RS256, ES256, EdDSA — and it generates a key of the right type, with the right curve, and with the metadata that makes it usable.

The Key Pair Generator already makes keys, and this is a different question. That tool starts from *what kind of key* and hands back PEM, which is what a TLS stack or an SSH client wants. This starts from alg and hands back the JOSE fields around the key: kty, use, key_ops, and a kid. Those fields are where the time goes when a key set is assembled by hand, and getting them wrong is quiet — a JWKS with no alg parses perfectly and fails at the other end for reasons that take an afternoon to find.

The kid is the RFC 7638 thumbprint rather than a random string, and that is worth more than it looks. A thumbprint is computed from the key itself, so everybody holding the key derives the same id for it without being told — which is what a key id is for. A uuid means both ends have to agree on a name for something they can already both see.

A symmetric algorithm gets no public key and no key set. HS256 has one secret; whoever can verify a token with it can also issue one, so there is nothing here that could be published by accident. That restriction is the single most useful thing this tool does, because a shared secret in a /.well-known/jwks.json is an authentication bypass served over HTTPS.

Everything is generated in this tab with Web Crypto. The private key is masked until you ask for it, and it is never sent anywhere.

Where it helps

• Starts from the alg in the token header rather than from a key type, so the key matches what you will write.
• Fills in kty, use, key_ops and kid, which is the part people get wrong by hand.
• The kid is the RFC 7638 thumbprint, so both ends derive the same id for the same key with no coordination.
• Hands you the JWKS ready to serve, with only the public half in it.
• Three separate outputs rather than one block — the private key, the public key and the key set go three different places, and only the private one is masked.
• Converts a PEM you already have, deriving the public half and the thumbprint from it.
• Reads the algorithm out of the key rather than asking, and says when the key genuinely does not determine it.
• Refuses to produce a key set for a shared secret, because that would publish the thing that signs.
• Generated in this tab with Web Crypto — the private key is never sent anywhere.

Limits

• It reads PKCS#8 and SPKI PEM. A PKCS#1 key (-----BEGIN RSA PRIVATE KEY-----) or an encrypted one has to be converted with openssl first, and the error says how.
• For an RSA key the algorithm cannot be read off the file, only narrowed to six — so the suggestion is a default and the choice stays with you.
• The curve and hash are fixed by the algorithm name and not offered as choices, because JOSE fixes them — an ES256 key on P-384 is not stronger, it is invalid.
• EdDSA needs a browser that has shipped Ed25519 in Web Crypto, and not all of them have.
• A key set here holds one key. Rotation means serving the old and new keys together for a while, which is a deployment question rather than a generation one.
• Nothing here manages keys once they exist — no rotation schedule, no expiry, no storage.

Frequently asked questions

What goes in my JWKS, and what must not?

Only the public key. It verifies and cannot sign, which is why publishing it at a URL is safe and useful. The private key signs; anyone who gets it can mint tokens your service will accept. They are one copy-paste apart, which is why the private one is masked here and the block that is safe to publish is labelled.

Why is the kid a long base64 string rather than something readable?

Because it is derived from the key. RFC 7638 hashes the key's required members in a canonical form, so the same key always produces the same id, for everybody, with no agreement needed. You can use any string you like as a kid — dates are common — but then the two ends have to be told what it is.

Should I use RS256 or ES256?

ES256 unless something forces RSA. The keys and signatures are a fraction of the size, which shows up in every token you issue, and the security margin is better. RS256 is the safe choice for interoperability because everything accepts it; PS256 is the one to pick if you need RSA and control both ends.

How does it know which algorithm my PEM is for?

Both PKCS#8 and SPKI begin with an AlgorithmIdentifier — an OID naming the algorithm, and for elliptic curves a second one naming the curve. For an EC or Ed25519 key that settles it: JOSE pairs each curve with exactly one hash, so P-256 is ES256 and nothing else. For RSA it does not settle it, because RS256 and PS256 are the same key with different padding and RS256 and RS512 the same key with different hashes — so there the tool offers a default, says it is a default, and leaves the choice with you.

Why does ES512 use P-521?

Because the algorithm is named for its hash and the curve is named for its field size, and the two happen not to match. ES512 is ECDSA with SHA-512 on P-521. A key generated on a made-up P-512 curve will not verify anywhere, and it is a common enough mistake that the tool says so.

Related tools

• Key Pair Generator — RSA and elliptic-curve key pairs, generated in this tab and never sent
• JWT — Read, verify and sign JSON Web Tokens
• Hash Generator — SHA-2, SHA-3, BLAKE and legacy digests, in any encoding
• UUID Generator — UUID v1 to v7 — generate any version, or read what one encodes
• MD5 Generator — MD5 digests, with a plain account of what they are still good for
• HMAC Generator — Keyed message authentication codes

More Security & Cryptography tools

• Hash Generator — SHA-2, SHA-3, BLAKE and legacy digests, in any encoding
• MD5 Generator — MD5 digests, with a plain account of what they are still good for
• HMAC Generator — Keyed message authentication codes
• Key Derivation — Stretch a passphrase into key material with PBKDF2, scrypt or Argon2id
• Password Generator — Strong random passwords with an entropy estimate
• Password Strength — Judge a password by what an attacker would actually try
• JWK Generator — A JSON Web Key for a JOSE algorithm, with its key set and thumbprint id
• Key Pair Generator — RSA and elliptic-curve key pairs, generated in this tab and never sent
• TOTP / HOTP Generator — Two-factor codes, the QR code to enrol with, and why one did not match
• Text Encryption — AES-256-GCM with a PBKDF2 passphrase
• Bcrypt Generator — Hash a password with bcrypt, verify one against a hash, or read what a hash is made of