nsec vs npub: what each one is, and how not to mix them up

Every Nostr user sees two strings that start with npub1 and nsec1 within a minute of creating an account. They look almost identical, they are the same length, and they both look like random characters. Mixing them up is one of the most common and most consequential mistakes on the network.

This guide makes the distinction stick, visually and conceptually, so you never confuse them again.

TL;DR. npub1... is your public key: safe to share, this is what you hand out. nsec1... is your private key: never share, never paste into a website, never save to cloud notes. Both are 63 characters long. The first three letters are the only thing that matters.

When you are ready, grab your @nostr.blog address →

The one-line distinction

Your key pair has two halves.

• npub = nostr public. The identifier you post, share, and use as your "account name."
• nsec = nostr secret. The cryptographic secret that proves you own the account.

"npub" contains the word "pub" for public. "nsec" contains "sec" for secret. This mnemonic is not accidental; the designers picked prefixes to be self-explanatory.

What you actually see

Both strings are 63 characters. Both start with n and then a three-letter prefix. Both use lowercase a-z and digits 0-9 from a restricted Bech32 alphabet.

npub example:

npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5

nsec example (this one is fabricated; never share a real nsec):

nsec1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq

They differ only in the prefix after the n. pub vs sec. Every other character could be anything; that prefix is the single place you can tell them apart.

Where each one comes from

When you launch a Nostr client for the first time, it generates 32 random bytes and calls those your private key. This becomes your nsec after Bech32 encoding. Then the client runs one mathematical operation (elliptic curve multiplication on secp256k1) to derive a matching public key, and Bech32-encodes that as your npub.

The relationship is one-way. Given the nsec, deriving the npub is fast. Given the npub, deriving the nsec back is believed to be impossible with any computer that exists or is likely to exist.

This is why you can publish your npub on your website, on Twitter, on business cards, and in your email signature without any security consequence. It is also why losing your nsec is an unrecoverable catastrophe: nobody, not even you, can reconstruct it from the npub.

What each key is used for

The nsec has exactly one job: sign events. Every time you post, react, follow someone, update your profile, or send a direct message, your client creates an event and signs it using the nsec. The signature goes into the event before it is published to relays.

The npub has several jobs:

• Identity. When someone follows you, they reference your npub.
• Verification. Every client that receives an event checks the signature against the npub attached to the event. A valid signature means the event came from whoever owns the matching nsec.
• Routing. Relays use the npub in filters. Subscribing to "events from npub X" is how your followers get your posts.
• Mentions. When someone tags you in a post, they embed your npub in the event tags.

The nsec never appears on the network. It stays on your device (or a trusted signer like a NIP-07 extension or a remote signer app). The npub is on the network constantly, attached to every event you sign.

Common mix-ups and their consequences

Mix-up 1: Pasting your nsec where an npub is asked for.

Scenario: a profile edit form says "your public key" and you paste the nsec by accident. Consequence: depending on the client, the form may warn you (good clients check the prefix and reject nsec in public fields). Bad clients might publish the nsec somewhere it should not go. Always check the three-letter prefix before pasting.

Mix-up 2: Publishing your nsec on social media as a demo.

Every year, a new user posts a screenshot of their "Nostr account details" that includes both strings. Consequence: anyone who sees the screenshot can now sign events as that user until they realize what happened and rotate. The fix is to only share the npub half.

Mix-up 3: Saving the nsec in cloud notes "temporarily."

Scenario: you generate a key pair, want to copy it to a second device, and paste the nsec into iCloud Notes or a Gmail draft to move it across. Consequence: that provider now holds your nsec in a form they can read. A breach of that provider is a breach of your Nostr identity. Use a password manager with end-to-end encryption, or (for one-time transfer) a QR code that you scan between devices without storing in a cloud-synced location.

Mix-up 4: Pasting the nsec into a website login form.

Scenario: a new Nostr web app asks for your nsec to "log you in." Consequence: that website now has your nsec permanently, even after you close the tab. Never do this. Reputable web clients use a NIP-07 browser extension instead; the extension holds the nsec and only signs on request, never exposing the raw secret to the web page.

The Bech32 checksum trick

Both npub and nsec use Bech32 encoding, which includes a built-in error-detection checksum. If you change one character of an npub or nsec, the checksum fails and any compliant tool rejects the string as invalid.

This is useful in practice: if you copy-paste a key and a character gets dropped or substituted, the receiving tool will tell you immediately, rather than silently accepting a different (valid-looking) identity.

Hex-encoded keys do not have this property. A single wrong character in a hex key produces a different but "valid" key pointing at a completely different identity. Always prefer the Bech32 form (npub/nsec) when pasting keys between systems.

How to check which one you are looking at

The first four characters. That is the entire check.

• Starts with npub1: safe to share, it is the public half.
• Starts with nsec1: do not share under any circumstance, it is the secret half.
• Starts with note1: this is an event ID (for a specific post), not a key.
• Starts with nprofile1: this is a public key bundled with recommended relays.
• Starts with nevent1: this is an event ID bundled with author and relays.
• Starts with naddr1: this is a long-form article address.

A useful mental rule: any Bech32 string that starts with nsec stays on your device. Everything else (npub, note, nprofile, nevent, naddr) is meant to be shared.

A concrete safety ritual

The moment you generate a new Nostr identity, do this:

1. Open your password manager.
2. Create a new entry labeled "Nostr nsec [account name]."
3. Paste the nsec into the password field.
4. Save.
5. Close the app.

Total time: 30 seconds. Alternative: print the nsec on a piece of paper with a reliable printer and store the paper somewhere you will not lose. Five minutes.

Now you have a recovery path. The nsec is in a place encrypted with your master password or offline entirely. If you lose your phone, you can log in on the new one by pasting the nsec back. If you lose your laptop, same.

The one place people resist this: they generate keys on their phone, the nsec is in the keychain, "I'll back it up later." Later never comes. Then they wipe the phone, or upgrade, or lose it, and the identity is gone. The backup is the single step that prevents this and it takes less time than reading this paragraph.