NIP-19: bech32-encoded entities
Nostr needed identifiers people could safely pass around
NIP-19 is the reason Nostr has words like npub, nsec, note, nevent and naddr. Before it, a public key, a private key and an event ID could all look like the same 32-byte hex string. That is fine for protocol internals and terrible for humans.
The standard uses bech32, familiar from Bitcoin address design, because it gives readable prefixes, copy-paste resilience and QR-friendly strings. A user can see the difference between a public identity and a private key. A client can accept a shared event reference with relay hints. A publisher can link to an addressable article without asking you to parse raw coordinates.
The NIP is also careful about scope. Bech32 strings are for display, sharing, QR codes and input. NIP-01 events, filters and NIP-05 JSON still use hex or binary forms internally. That boundary matters. NIP-19 improves the human interface; it is not a new wire format for events.
Bare keys, event IDs and TLV records
The bare forms are the easy layer. npub is a public key, nsec is a private key and note is an event ID. These forms carry exactly the underlying 32-byte value with a prefix that tells humans and software what kind of thing they are touching.
The shareable forms use TLV, or type-length-value, records. nprofile can include a public key plus relay hints. nevent can include an event ID, relays, author and kind. naddr identifies addressable events through a d tag value, author pubkey and kind. Those extra fields help a client locate and display an object after a user pastes a link from somewhere else.
The file also records ecosystem learning. nrelay is now deprecated. Unknown TLV types are ignored instead of treated as fatal errors. Bech32 strings are limited in size to 5000 characters. Each of those details comes from real implementation pressure: extensibility, compatibility and the need to prevent absurdly long share strings.
The standard grew from keys into portable coordinates
Fiatjaf added NIP-19 in December 2022. The early commits clarified purpose and examples, and SondreB updated key-pair examples in February 2023. Then the standard started following product reality: profiles and notes were no longer enough. Long-form content, replaceable events and app objects needed shareable coordinates.
The 2023 history shows that growth. Semisol added bech32 relay entities. Fiatjaf introduced and then renamed item references, moving from nref to nitem and finally toward naddr. Mike Dilger added the rule that unknown TLV types are ignored. Jonathan Staab defined how non-parameterized replaceable events can encode as naddr.
Later changes renamed parameterized replaceable events to addressable events, deprecated nrelay and added the 5000-character limit in March 2026. The arc is clear: NIP-19 began as safer human-readable keys and became the sharing layer for a much wider Nostr object world.
Every serious client touches NIP-19 sooner or later
NIP-19 is heavily implemented because users constantly paste identifiers. nostr-tools exposes a nip19.ts module for encoding and decoding these forms. Rust Nostr documents NIP-19 as the transportable identifier layer and supports parsing across public keys, event IDs and coordinates. nostr-core exposes the same family of helpers in its API documentation.
The hard implementation work is not just bech32 decoding. Clients have to normalize input, reject nsec in dangerous contexts, preserve relay hints without trusting them blindly, ignore unknown TLVs, handle very long naddr strings and map display strings back to the hex forms required by NIP-01 and NIP-05.
The issue trail around naddr makes this concrete. nostr-tools issue #134 shows developers hitting trouble decoding long-form article addresses. nostr-php issue #74 describes bech32 length problems when a generic bech32 library assumes a shorter limit. NIP-19 is simple to explain, but brittle to implement if a library treats it as ordinary Bitcoin-address bech32 without Nostr's longer TLV cases.
Readable strings can make dangerous strings feel harmless
The obvious danger is nsec. A friendly prefix does not make a private key safe to paste into websites, forms or screenshots. A good client treats nsec differently from npub and warns users before import or exposure.
The quieter risk is over-trusting metadata. Relay hints inside nprofile, nevent or naddr help discovery, but they are hints, not truth. A client still has to verify signatures, event IDs and authorship. NIP-19 helps you find the thing; NIP-01 still tells you whether the thing is valid.
Read NIP-19 in the wild
NIP-19 is why Nostr identifiers became human-shareable. npub, nsec, note, nevent, nprofile and naddr wrap raw keys and event coordinates into bech32 strings that people can copy without understanding the underlying bytes.
The user safety part is just as important as the encoding. An nsec is secret, an npub is public, a note points to an event, and an naddr points to an addressable object. If the UI blurs those differences, the nice encoding becomes dangerous.
What changes when you actually use it
For you, NIP-19: bech32-encoded entities is felt when identity stops being a username and becomes authority. A client, signer, name, proof or auth event may look like account plumbing, but it decides who can publish, approve, connect, recover or be recognized. Read NIP-01, NIP-05 beside it so you can tell the difference between a convenient identity surface and the key material that actually controls the account.
What changes for builders and operators
For builders, NIP-19: bech32-encoded entities means making authority visible before action. A signer prompt, name proof, delegation, encrypted key, external identity or HTTP auth event needs plain language around scope, expiry, destination and recovery. If a person has to guess what they are authorizing, the protocol has already lost the trust battle.
What the official file makes concrete
The official file is organized around Bare keys and ids, Shareable identifiers with extra metadata, Examples, Notes. Inspect draft, npub, nsec, note, npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6, T, nprofile, nevent because these are the pieces most likely to surface as product behavior. Read it beside NIP-01, NIP-05 before treating it as isolated.
NIP-19: bech32-encoded entities is an authority path, not decoration. A name, key, signer, delegation or auth event decides who can act as you.
Where it breaks
The failure mode in NIP-19: bech32-encoded entities is authority drift. A name resolves to an old key, a signer approves too broadly, an auth event gets replayed, a delegation lasts too long or a private key backup gives false comfort. The product has to keep control boundaries visible after onboarding, not only during setup.
Where this appears outside the markdown
In the ecosystem, NIP-19: bech32-encoded entities usually appears at the doorway: account setup, profile recognition, signer approval, cross-platform proof, remote signing, HTTP auth or recovery. That doorway needs unusually clear language because identity mistakes are sticky. Once a key, signer or proof is trusted in the wrong place, every later feature inherits the confusion.
The nearby-standard trap
The nearby-standard trap in NIP-19: bech32-encoded entities is confusing recognition with control. A name, signer, URI, encrypted key, delegation or auth signature may all sit near identity, but they answer different questions. Read NIP-01, NIP-05 and ask one thing each time: who can act, who can verify, and what can be revoked?
Language that keeps the feature honest
Good product copy for NIP-19: bech32-encoded entities names the authority. It says whether you are sharing a public key, approving a signature, trusting a domain, exporting an encrypted secret, delegating power or authenticating to a service. Small labels matter because identity mistakes do not feel small after they happen.
What this page does not promise
NIP-19: bech32-encoded entities does not make identity effortless or risk-free. It can help keys, names, signers, delegation or authentication become portable, but it cannot decide who you trust, how you back up secrets or whether a domain, app or signer deserves authority. Read NIP-01, NIP-05 as a control map before handing any interface the power to sign, verify or speak for you.
Read it as a field test
Start NIP-19: bech32-encoded entities with the moment of authority: signing, naming, delegation, authentication, encryption or recovery. Then ask which key or service can act. The source terms draft, npub, nsec, note, npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6, T are useful because they turn vague identity language into concrete control points. Without that, a friendly login screen can hide the most important security decision.
Where the standard earns trust
The source links give you places to test the interpretation in public: nostr-tools nip19.ts, Rust Nostr Book: NIP-19, nostr-core NIP-19 API, nostr-tools issue #134. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-19 source is the anchor for exact wording, and NIP-19 commit history shows how that wording moved over time. The strongest secondary clues here are nostr-tools nip19.ts, Rust Nostr Book: NIP-19, nostr-core NIP-19 API. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-19: bech32-encoded entities: first the human promise, then draft, npub, nsec, note, npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6, T, then the implementation record, then the real-world failure case. That order keeps NIP-19 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who gains authority when this NIP is used: your key, a signer, a domain, a delegated key, a wallet or a web service?
- Can you revoke, rotate, back up or inspect that authority before something goes wrong?
- Does the interface separate public recognition from private signing power in language you can act on?
What to verify before you rely on it
- Find
draft,npub,nsec,note,npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6in the official file and check where the UI exposes the same concept. - Read NIP-01, NIP-05 as context before treating NIP-19 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-19: bech32-encoded entities in that order: Official NIP-19 source for the current wording; NIP-19 commit history for the change record; nostr-tools nip19.ts, Rust Nostr Book: NIP-19, nostr-core NIP-19 API for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
