ECDSA sign
Sign a file with an ECDSA private key, on your device.
Runs on your device. The file is never uploaded.
ECDSA sign imports a PKCS8 key for the curve you name and signs the whole file, letting that curve pick the hash. The signature returns as hex, 128 characters on P-256. It is the raw Web Crypto form with no DER wrapper around it, so an OpenSSL tool wants a conversion first.
Questions
Why do I have to tell it the curve?
Because a PKCS8 private key is imported for a named curve, and Web Crypto needs that name up front. Set it to whatever ECDSA key pair generate used: P-256, P-384 or P-521, default P-256. The curve also decides the hash, SHA-256 for P-256, SHA-384 for P-384 and SHA-512 for P-521, so choosing wrongly makes the import fail rather than producing a bad signature.
What gets signed?
The entire file as dropped, byte for byte. There is no canonicalisation, no whitespace handling and no metadata. The filename is not part of the signature. One changed byte, including a trailing newline added by an editor when it saved the file, makes ECDSA verify report invalid.
What is the output?
The signature as a hex string on the page. It is the raw bytes crypto.subtle.sign returns, converted to hex with nothing added around them, so it is twice the curve field size: 64 bytes and 128 hex characters for P-256. Paste it into ECDSA verify with the same file, the matching public key and the same curve.
Why does signing the same file twice give different hex?
ECDSA picks a fresh nonce for every signature, so each run over the same file with the same key produces different bytes, and all of them verify. This is normal and expected. It also means a signature is not a fingerprint; for a stable per-file value use Generate all hashes or a dedicated hash tool.
Will another library accept this signature?
It depends on the encoding that library expects. This tool emits exactly what Web Crypto produces, with no DER wrapping added. Tools built around OpenSSL usually want a DER-encoded signature instead, so a conversion step is needed when the other tool expects DER. ECDSA verify on this site reads the same form this one writes, so a round trip here always works.
Where does the private key go?
It is decoded from PEM and imported by crypto.subtle in a Web Worker in this tab, non-extractable, then discarded when the run ends. Nothing is uploaded, nothing is stored, and the tool works with the network off. Pasting a real private key into a browser page is still a decision about the device you are using.