A key pair, generated on your machine
Your browser produces the key material and it never leaves the page. The public half is for sharing; the private half is the thing itself, and once this tab closes it is gone unless you saved it.
Public key
Safe to publish. Give this to anyone who needs to verify your signatures.
Private key
Never share this. Anyone who has it can sign as you, and it cannot be reissued — this page keeps no copy.
Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.
What happens when you press the button
crypto.subtle.generateKey is called with the algorithm you chose. The browser draws the key material from the operating system's cryptographically secure generator — the same source it uses for TLS — and returns a pair of key objects. They are then exported: the public key as SPKI, the private key as PKCS#8, both wrapped in PEM.
Nothing else happens. There is no request, no logging, and no copy kept anywhere. When this tab closes, a private key you did not save has ceased to exist, and no one can recover it.
Every generated pair is immediately checked end to end: the exported public key is re-imported, a random message is signed with the private key and verified with the re-imported public one. If that fails you are told, rather than being handed a pair that does not work.
The two halves are not interchangeable
The public key can be published, emailed, put in a repository or printed on a business card. Everything it lets someone do — verify your signatures — is something you want them to be able to do.
The private key is the identity. Anyone holding it can sign as you indefinitely, and there is no revocation here to stop them. It should be stored the way you would store a password: in a password manager, or a file only you can read, or a hardware token. Not in a shared drive, not in a repository, and not in a chat message.
The private key file produced here is not encrypted. PKCS#8 supports a password-protected form and Web Crypto does not implement it, so rather than invent something, this page exports the plain form and says so. If you need it protected at rest, encrypt the file with the file encryption tool or store it somewhere already encrypted.
What this tool does not claim
No tool on this site is described as unbreakable, military grade, or completely secure, because none of those phrases means anything a person could check. What is written down instead is which standard is used, which library implements it, and what the tool has been tested against.
Everything here runs in your browser using its built-in Web Crypto implementation. Nothing is uploaded, and there is no server that could receive it. That is a real and checkable property — open your browser's network tab and use the tool.
Which algorithm
ECDSA P-256 is the sensible default: small keys, small signatures, fast, and supported by every browser and nearly every library.
Ed25519 is the better modern design and produces the same size signature. It is deterministic — signing the same message twice with the same key gives the same signature — which removes an entire class of failure that has broken ECDSA implementations in the field. Browser support arrived recently, so it is only offered where it works.
RSA at 2048 or 4096 bits is offered because a great deal of software still expects it. Keys are far larger, signatures are 256 or 512 bytes against 64, and generating 4096 bits takes several seconds. It is not more secure at these sizes; it is more compatible.
What this key is not for
These are signing keys. They authenticate content; they do not encrypt it. Encrypting to somebody's public key is a different operation with different key types, and mixing them up is one of the more common misunderstandings in this area.
They are also not SSH keys, TLS certificates or PGP keys. Those formats wrap key material in additional structure — comments, identities, certificate fields, expiry — that this page does not produce. A raw PEM key pair is what you need for signature verification in code, and not what ssh-copy-id or a certificate authority expects.
Related
Sign something with the key you just made, or inspect a public key somebody sent you.
Questions people actually ask
Where is the key generated?
In your browser, by crypto.subtle.generateKey, using the operating system's cryptographically secure random generator — the same source your browser uses for TLS. There is no request to any server and no copy kept anywhere.
What happens if I close the tab?
A private key you did not save ceases to exist. Nothing is stored, there is no account, and it cannot be regenerated — the same algorithm run again produces a different key. Save it before you close the tab or accept that it is gone.
Is the private key file encrypted?
No, and the page says so rather than implying otherwise. PKCS#8 has a password-protected form but Web Crypto does not implement it, and inventing our own would break the rule this whole category rests on. If you need it protected at rest, encrypt the file with the file encryption tool or store it somewhere already encrypted.
Can I use this as an SSH key or a TLS certificate?
No. Those formats wrap key material in extra structure — comments and identities for SSH, certificate fields and a signature for TLS — that this page does not produce. What you get here is a raw PEM key pair, which is what code needs for signature verification and not what ssh-copy-id or a certificate authority expects.
Can I encrypt something to this public key?
Not with these. They are signing keys: they authenticate content rather than concealing it. Encrypting to a public key is a different operation with different key types, and conflating the two is one of the commoner misunderstandings in this area.
Why is Ed25519 sometimes unavailable?
Because browser support for it is recent. Where the browser cannot do it, the option is disabled and labelled rather than silently substituting something else. ECDSA P-256 works everywhere and is the sensible default.