Hashing the message first
ECDSA never signs raw message bytes directly — the hash: "SHA-256" parameter in this tool's sign() call means your message is reduced to a 256-bit digest first, and everything below operates on that digest, not your original text.
Choosing k and computing (r, s)
Your browser generates a fresh random nonce k for this specific signature — never reused, never exposed by this tool — and combines it with your private key exactly as covered in the ECC module's nonce-leak section.
The signature you copy is raw r‖s, not DER
The base64 string this tool shows you decodes to exactly 64 bytes for P-256: the 32-byte big-endian r immediately followed by the 32-byte big-endian s (the IEEE P1363 format). This is a Web Crypto–specific choice — most other libraries, and the ASN.1 DER encoding used inside X.509 certificates, wrap r and s in a different structure, so raw Web Crypto signatures aren't directly interchangeable with those formats without conversion.
Verifying: recomputing a point, not decrypting
Verification is not "decrypt the signature and compare" — ECDSA has no decryption step. Instead, the verifier computes two values from the signature and the public key, uses them to reconstruct a curve point, and checks whether that point's x-coordinate equals r.
Swap in a different public key, as this tool's "wrong key" button does, and Q changes — which changes the reconstructed point entirely. The odds that an unrelated point's x-coordinate happens to equal the original r are astronomically small, which is exactly why verification fails cleanly rather than partially.