ECDSA Key Generator

Generate an ECDSA elliptic-curve key pair without installing OpenSSL. Choose a curve — P-256, P-384 or P-521 — and an output format, and get a matching private and public key as PEM (PKCS#8 / SPKI) or JWK, ready for JWT signing, TLS, SSH or any ECDSA workflow. The keys are produced by your browser's Web Crypto implementation using a cryptographically secure generator, and the private key is never transmitted or stored anywhere.

How to use the ECDSA Key Generator

Pick the curve you need and a format, then press Generate new key pair — a fresh pair appears immediately, and you can regenerate as many times as you like. P-256 is the default for most applications, including the ES256 JWT algorithm and modern TLS; P-384 (ES384) and P-521 (ES512) offer higher security margins where required. The PEM output gives you the private key in PKCS#8 (BEGIN PRIVATE KEY) and the public key in SubjectPublicKeyInfo (BEGIN PUBLIC KEY) form, which is what almost every library and command-line tool expects. Choose JWK instead if you're working with JOSE, OIDC or a JavaScript crypto stack that consumes JSON Web Keys.

Copy the keys with the buttons or select the text directly. Because generation happens in your browser through the Web Crypto API, the private key is created locally and never sent over the network — but that also means it isn't stored, so if you navigate away it's gone. Save the private key somewhere secure before closing the tab, and treat it like any other secret: never paste a production private key into a page you don't control, and prefer generating production keys in your own environment when policy requires it.

ECDSA and the NIST curves

ECDSA — the Elliptic Curve Digital Signature Algorithm — is the elliptic-curve counterpart to RSA signatures, and it has become the default for new systems because it delivers equivalent security with dramatically smaller keys. A 256-bit elliptic-curve key offers roughly the same resistance to attack as a 3072-bit RSA key, which means shorter signatures, faster operations and less data on the wire. That efficiency is why ECDSA underpins so much modern infrastructure: TLS certificates, JWT and JOSE signing (the ES256/384/512 algorithms), SSH keys, code signing, and the signatures in most blockchains.

The curve you choose sets the security level. P-256, also called secp256r1 or prime256v1, is the workhorse — widely supported, fast, and sufficient for the overwhelming majority of uses. P-384 and P-521 raise the bar for systems with stricter requirements or longer protection horizons, at the cost of larger keys and slower operations. All three are NIST-standardised prime curves, supported natively by the Web Crypto API, OpenSSL and essentially every TLS and JOSE library, which is what makes a browser-generated key immediately usable everywhere.

A key pair is two linked values: a private key, a secret number you must protect, and a public key, a point on the curve derived from it that you can share freely. You sign with the private key and anyone verifies with the public one; recovering the private key from the public key is computationally infeasible, which is the whole foundation of the scheme. The formats simply package those values: PKCS#8 and SubjectPublicKeyInfo are the standard DER/PEM containers, while a JWK expresses the same key as JSON. Whichever you pick, the security rests entirely on keeping the private key secret and on the quality of the random number used to create it — both of which are handled here by your browser's vetted cryptographic generator.

Common use cases

  • JWT signing keys. Generate an ES256/384/512 key pair for issuing and verifying JSON Web Tokens.
  • TLS and mTLS. Produce an EC key to pair with a certificate or signing request.
  • Local development. Spin up throwaway key pairs for testing without reaching for OpenSSL.
  • Learning. Inspect the PEM and JWK representations of the same key side by side.

Frequently asked questions

Is the private key sent to a server?
No. The key pair is generated entirely in your browser by the Web Crypto API and never leaves your machine. It is also not stored, so save the private key before you close the tab — there is no way to recover it afterwards.

Which curve should I choose?
P-256 (prime256v1) is the right default for almost everything: it powers ES256 JWTs and modern TLS, and is the most widely supported. Use P-384 (ES384) or P-521 (ES512) only when a policy or threat model calls for a higher security margin, accepting larger keys and slower operations.

What is the difference between PEM and JWK output?
PEM is the base64 DER container nearly every tool expects — PKCS#8 for the private key and SubjectPublicKeyInfo for the public key. JWK expresses the same key as a JSON Web Key, which is convenient for JOSE, OIDC and JavaScript crypto libraries. They hold the same key in different wrappers.

Can I use these keys in production?
They are real, standards-compliant keys generated with a cryptographically secure random source, so technically yes. But for production it is generally best practice to generate keys inside the environment that will use them, with appropriate access controls, rather than in a browser tab. Use your judgement and follow your organisation's policy.

Why is ECDSA preferred over RSA?
Elliptic-curve keys achieve the same security as RSA with far smaller keys — a 256-bit EC key is roughly comparable to a 3072-bit RSA key — giving shorter signatures and faster operations. That efficiency has made ECDSA the default for new TLS, JWT, SSH and code-signing deployments.