ECDSA Sign Message Online
Create an ECDSA digital signature using your elliptic curve private key, directly in the browser. Supports NIST curves P-256, P-384, and P-521 with SHA-256, SHA-384, or SHA-512. The signature is in IEEE P1363 format — compatible with JWT (ES256/ES384/ES512) and most modern cryptographic libraries. Your private key never leaves your device.
ECDSA Signature Properties
- Probabilistic: Each signing produces a different signature — all are valid for the same message
- Non-repudiation: Only the private key holder can produce a valid signature
- Integrity: Any change to the message invalidates the signature
- Small signatures: 64 bytes for P-256, vs 256–512 bytes for RSA
Signature Size by Curve
| Curve | Signature size (P1363) | JWT alg |
|---|---|---|
| P-256 + SHA-256 | 64 bytes | ES256 |
| P-384 + SHA-384 | 96 bytes | ES384 |
| P-521 + SHA-512 | 132 bytes | ES512 |
Common Use Cases
- JWT token signing (ES256 = P-256 + SHA-256)
- TLS client certificate authentication
- Code signing and software distribution
- Blockchain transaction signing (Bitcoin, Ethereum use secp256k1 — not available here)
- API request signing and authentication
Frequently Asked Questions
Does ECDSA produce the same signature every time?
No. ECDSA is probabilistic — each signing operation uses a random nonce (k), so the same message signed twice with the same key produces different signatures. Both are valid. This is by design and is a security requirement. (Reusing the nonce k is a catastrophic vulnerability — it allows private key recovery. This is what happened in the PlayStation 3 hack. The Web Crypto API handles nonce generation securely.)
What format is the ECDSA signature?
The Web Crypto API outputs ECDSA signatures in IEEE P1363 format (raw r||s concatenation), not DER format. P1363 format is two integers concatenated directly: 64 bytes for P-256 (32+32), 96 bytes for P-384 (48+48), 132 bytes for P-521 (66+66). This is the format used by JWT (ES256, ES384, ES512). Some other libraries (OpenSSL, Java) use DER format — conversion may be required for interoperability.
How does ECDSA signing work?
ECDSA signing: (1) hash the message with the chosen algorithm (SHA-256 for P-256), (2) generate a random nonce k, (3) compute a point on the elliptic curve using k, (4) compute signature values r and s from the hash, nonce, and private key. Verification reverses this: given the signature and public key, reconstruct the curve point and check it matches r.
What is the relationship between ECDSA and JWT (ES256)?
ES256 in JWT uses ECDSA with P-256 and SHA-256. ES384 uses P-384 + SHA-384. ES512 uses P-521 + SHA-512. The signature format is P1363 (which is what Web Crypto outputs). If you need to sign a JWT payload, note that JWT signs the base64url-encoded header + payload, not raw text.
ECDSA vs EdDSA (Ed25519) — which is better?
EdDSA (Ed25519) is newer and generally considered superior for new systems: it is deterministic (no random nonce — eliminates a class of implementation bugs), faster, and has a simpler security proof. However, it is not yet supported by the Web Crypto API in all browsers for general use. ECDSA with P-256 remains the widely deployed standard for TLS, JWT, and SSH.
Can ECDSA keys be used for encryption?
No. ECDSA is a signing-only algorithm. For encryption with elliptic curves, use ECDH (Elliptic Curve Diffie-Hellman) key agreement to establish a shared AES key. For public-key encryption, use RSA-OAEP.