Conversor JWK ⇄ PEM ⇄ SSH online

One key, many encodings

A public key is a handful of numbers: an elliptic-curve point, an Edwards or Montgomery key of 32 or 57 bytes, or an RSA modulus and exponent. Every format you meet wraps the same numbers differently, and no library accepts them all: Go's x509 package wants DER, Web Crypto a JWK or SPKI, OpenSSH its own one-line format, a hardware wallet the bare point. The converter reads one form and writes all the others, so the bytes never have to be reshaped by hand.

How the input is recognised

The input is identified by its shape, in this order:

1. JSON is read as a JWK (RFC 7517). Members other than the key material — kid, use, alg, x5c — are kept unless you change them.
2. PEM is read by its label: PUBLIC KEY is SubjectPublicKeyInfo (SPKI), PRIVATE KEY is PKCS #8, EC PRIVATE KEY is SEC 1, RSA PUBLIC KEY and RSA PRIVATE KEY are PKCS #1, CERTIFICATE and CERTIFICATE REQUEST give up the key they carry. Encrypted PKCS #8 is refused with an explanation: decrypting it needs the password, and the password belongs in your terminal, not on a web page.
3. OpenSSH lines (ssh-ed25519 AAAA…, ecdsa-sha2-nistp256 …, ssh-rsa …), RFC 4716 ---- BEGIN SSH2 PUBLIC KEY ---- blocks and OPENSSH PRIVATE KEY files are decoded as SSH key blobs.
4. Hex or base64 is checked for a DER structure first. Otherwise it is raw key bytes: a 65-byte value starting with 04 can only be an uncompressed P-256 point, a 33-byte value starting with 02 or 03 a compressed one. A bare 32-byte value fits Ed25519, X25519 and a private scalar alike; the converter does not guess but asks how to read it — the Bare bytes are setting.

Whatever the input, the key is validated before anything is written: an EC point must lie on its curve (otherwise it invites invalid-curve attacks), an Edwards point must decode, the halves of a private key must belong together, and RSA keys are checked for an even modulus, a weak exponent and the ROCA fingerprint of a known flawed key generator.

What each format contains

• JWK. EC keys carry x and y, each padded to the full coordinate size of the curve (RFC 7518 §6.2.1.2: 66 bytes for P-521); RSA keys carry n and e without leading zero bytes (§6.3.1.1); Ed25519 and X25519 use kty OKP with a single x (RFC 8037). All values are base64url without padding.
• PEM and DER. PEM is base64 DER between -----BEGIN and -----END lines. SPKI names the algorithm with an OID — id-ecPublicKey plus the curve, rsaEncryption, id-Ed25519 (RFC 8410) — so it is the most portable public form.
• OpenSSH. A key type, a base64 blob and a comment (RFC 4253 §6.6, RFC 5656, RFC 8709). OpenSSH has no key type for secp256k1, X25519 or Ed448; the converter says so instead of writing something no SSH server would accept.
• Raw bytes. The SEC 1 point (uncompressed 04‖x‖y and compressed 02/03‖x), the 32-byte Edwards key, or the RSA modulus — what hardware wallets, embedded code and blockchain tooling usually expect.

The thumbprint

The RFC 7638 thumbprint is SHA-256 over a canonical JSON of the key's required members — {"crv":…,"kty":"EC","x":…,"y":…} for EC, {"e":…,"kty":"RSA","n":…} for RSA, crv, kty and x for OKP keys (RFC 8037 §2) — sorted, without whitespace. It identifies the key, not the encoding, so every form of one key has the same thumbprint, and it makes a good kid. The example above is the RSA key of RFC 7638 §3.1; the page shows that its thumbprint matches the one published in the RFC. RFC 9278 turns it into a URI.

Private keys stay on the page

Conversion runs in your browser on parsers that make no network request, so a private key can be converted here without leaving your machine. Its outputs are shown apart from the public ones, under a warning. Share links are stricter still: they carry a key only when it is public, and refuse private keys and shared secrets in any form. To publish the public half for your verifiers, take the JWK to the JWKS builder; to check a set that is already online, use the JWKS checker.