ECDSA Sign & Verify Online — P-256 / P-384 / P-521, JWT-Compatible

The math is identical — a pair of integers (r, s). The two encodings differ in how those bytes are laid out. JOSE (also called P1363, IEEE 1363) writes them as fixed-length concatenation r || s — 64 bytes for P-256, 96 for P-384, 132 for P-521. DER wraps them in an ASN.1 SEQUENCE, which is variable-length (typically 70-72 bytes for P-256). JWTs and WebCrypto default to JOSE; OpenSSL, OpenSSH, and most Go/Java crypto libraries default to DER. This tool outputs both so you can copy the one your verifier expects.

The JWT / NIST convention is: P-256 → SHA-256 (ES256), P-384 → SHA-384 (ES384), P-521 → SHA-512 (ES512). WebCrypto lets you mix (e.g. P-256 with SHA-384), but most verifiers don't and you'll get 'invalid signature' errors that are hard to debug. Stick with the conventional pairing unless you know the recipient supports otherwise.

You can verify the signature over any arbitrary message. For a JWT, the signed message is the two base64url-encoded parts joined by a dot: header.payload. Split the JWT on the last dot: the first part is the message, the last part is the base64url signature — you'll need to convert base64url to base64 (replace - with +, _ with /, add padding = if needed) before pasting. If you just want to inspect JWT structure, our JWT Decoder does that natively.

Encoding mismatch — you signed with the JOSE / P1363 format but OpenSSL expects DER (or vice versa). This tool outputs both when signing and auto-detects when verifying, but if you're passing signatures between systems, be explicit about which encoding you're using.

No — WebCrypto's ECDSA is randomized: each signature includes a fresh random nonce k. That means signing the same message twice gives you different signatures, both valid. This is the SEC1/FIPS-186 default. If you need deterministic ECDSA (RFC 6979) for reproducible signatures, use a library like noble-curves; WebCrypto doesn't expose that mode.