Nostr note converter

Three identifiers, three jobs

Nostr has several bech32 identifiers and they answer different questions. A note1 is the simplest: just an event id, 32 bytes naming one specific event, with no hint about where to find it. An nevent wraps that same id together with optional relay hints, the author's pubkey and the kind, so a client that has never seen the event knows where to start looking.

An naddr is different in kind, not just in size. It names a replaceable event by its coordinates: author, kind and an identifier tag, rather than by the hash of one version. That is why long form articles use naddr links: the article can be edited, and the naddr keeps pointing at the newest version instead of a stale snapshot.

What decoding shows you

Paste any of the three and this tool unpacks the fields locally: the raw hex id or coordinates, the author pubkey as hex and npub, the kind number, and any relay hints embedded in the pointer. Nothing is fetched and nothing is sent; decoding is pure parsing of the bech32 data you pasted.

This is handy when a link will not load in your client and you want to see why. If the nevent carries no relay hints, your client has to guess where the event lives. If the hints point at relays that have dropped the event, the pointer is honest but stale. Seeing the raw fields turns a mystery into a diagnosis.

Encoding in the other direction

Sometimes you have a raw hex event id from a relay query or a script and need a shareable link. Paste 64 hex characters and this tool produces the note1 form. For a pointer that includes relay hints or the author, generate it from a client that knows that context, since a converter cannot invent information the bare id does not contain.

Where an event actually lives depends on which relays accepted it, which is why publishing to reliable relays matters more than any identifier format.

If you build anything on Nostr, being able to read these identifiers by eye pays off quickly: spotting that a link is an naddr rather than an nevent tells you it targets living content, and a missing author field explains why a client cannot verify a pointer. The decoder simply makes that reading instant.