Nostr-Event-Verifizierer

What a Nostr event is

Everything on Nostr — a note, a profile, a reaction, a follow list — is an event: a JSON object with the author's public key, a timestamp, a numeric kind, a list of tags, the content, an id and a signature. Relays store and forward events, but they are not trusted: any client can check that an event really comes from its author, because the author signed it. NIP-01 defines the format; this page checks it the way a careful client does.

How the id is computed

The id is the SHA-256 of a canonical serialization: the JSON array [0, pubkey, created_at, kind, tags, content], written without spaces, with NIP-01's own string escaping — line feed, double quote, backslash, carriage return, tab, backspace and form feed are escaped, and every other character is written as it is. Many clients serialize with JSON.stringify instead, which also escapes the other control characters as \u00XX. The two agree unless a string contains such a character, so the verifier computes both ids and says which one the event's id matches. The exact string that is hashed is shown at the bottom of the result.

What the signature covers

The sig is a Schnorr signature over secp256k1 as defined by BIP-340 — the same scheme as Bitcoin's Taproot — made over the 32-byte id with the key whose x-coordinate is pubkey. The signature therefore commits to the id, and the id to the content. Comparing the stated id, the recomputed id and the signature separates the failures that matter:

• Modified after signing — the signature is valid for the stated id, but the content no longer hashes to it. The event was signed by its author and then changed by someone else: an edited note, an injected tag, a different timestamp.
• Wrong id — the signature covers the recomputed id, but the id field says something else. The content is authentic; the software that wrote the id is broken, and relays reject such events.
• Invalid signature — the id matches the content, but the signature was not made by this key over it: a forged or corrupted event.
• Forged or corrupted — neither the id nor the signature matches anything.

A public key that is not the x-coordinate of a point on the curve can never have a valid signature, and is reported as such.

Conventions it checks

Beyond validity, the verifier points out what other software may reject: hex fields written in upper case (NIP-01 requires lower case), a timestamp more than a few minutes in the future or one that predates Nostr, empty tags, e and p tags that do not hold 32-byte hex, a tags that are not a kind:pubkey:identifier coordinate, and addressable events (kinds 30000–39999) without a d tag. The kind is named from the registry in the NIPs repository and placed in its storage class: regular, replaceable, ephemeral or addressable. An event can be pasted on its own or as the ["EVENT", …] message a relay sends.

NIP-19 entities

NIP-19 defines bech32 strings for sharing: npub (a public key) and note (an event id) encode 32 bytes; nprofile, nevent and naddr encode a small type-length-value structure with relay hints, the author, the kind and, for addressable events, the identifier. The verifier decodes all of them, with or without the nostr: URI prefix, and shows the npub, note and nevent of every event it checks so they can be copied.

The secret key has its own prefix too: nsec. Anyone holding it can post as you, so it is refused wherever it appears — as is ncryptsec, the password-encrypted form of NIP-49, whose protection is only as strong as its password.

What runs locally

Everything: serialization, hashing, Schnorr verification (@noble/curves) and NIP-19 decoding run in your browser, and the page sends nothing anywhere — it does not ask relays for events, so paste the event you want to check. Share links carry the event or the entity in the URL fragment, which never reaches a server. Bitcoin addresses prove control with BIP-322 instead, checked by the Bitcoin message verifier; Solana wallets sign with Ed25519, checked by the Solana message verifier.