Keys are the account

Most accounts you have ever made are a row in somebody’s database. You prove you own the row with a password, and if you lose the password the company that owns the database lets you back in.

A Nostr identity is not a row anywhere. It is a number you chose at random, and a second number computed from it. Nobody issued it, nobody stores it, and nobody can restore it — because there is no “it” outside the number in your possession.

§1Look at a pair

Here is a real keypair, generated when this page was built. Both keys work; neither is worth anything, and the reason is the lesson.

That nsec is printed on a public web page. Anyone reading this can take it, sign events with it, and be indistinguishable from anyone else who took it. It is worthless — not because it is a weak key, but because it is not secret. A key is only ever worth the secrecy around it.

Which is the whole answer to the question people ask next: why can’t I just paste mine into a site to check it? Because the moment it is somewhere other than your own storage, it has the same value as the one above.

§2What the two forms are for

The protocol always uses hex. npub and nsec exist for humans: the same 32 bytes, wrapped in bech32 with a prefix and a checksum.1

The prefix is the part that matters. Two 64-character hex strings look identical, and one of them is catastrophic to share. npub1… and nsec1… do not — a person can tell them apart across a room, and software can refuse an nsec where an npub belongs before anything is transmitted. The checksum catches a typo instead of quietly producing a valid-but-different key.

That is a design decision about human error, not about cryptography, and it is a good one.

§3Where the secret actually lives

You cannot use Nostr without the private key signing things. The question every serious client answers is where, and there are four answers in circulation:

In the client. The app holds the key. Simple, and the entire security of your identity is now the security of one application and the device it runs on.

In a browser extension. The web page asks the extension to sign; the page never sees the key. This is what NIP-07 standardises, and it is the reason a well-built web client never has an nsec field at all.

In a remote signer. The key sits on a separate device or service that signs on request over relay messages. NIP-46 calls it a bunker. It moves the key off every device you browse from.

In hardware. The key never leaves a device that has no general-purpose software on it.

The ordering is roughly least to most cautious, and all four are better than the fifth option, which is pasting it into a website. There is no arrangement in which that is safe, and no site that needs you to.