How to back up your Nostr keys without losing them

The single most painful Nostr support request is "I lost my nsec, how do I get my account back." The answer is always the same: you do not. No company holds a copy. No cryptographic trick recovers it. The account is gone.

This guide is how to make sure that conversation never happens to you. Three backup strategies, ranked by safety and practicality, plus the specific mistakes that quietly produce an unrecoverable loss.

TL;DR. Save your nsec to a password manager with end-to-end encryption (1Password, Bitwarden, KeePassXC, or iCloud Keychain) the moment your client generates it. For high-value identities add a paper backup in a safe. Never save the nsec to iCloud Notes, Google Keep, a screenshot, or any cloud drive where the provider can read plaintext.

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

What you are actually backing up

Your Nostr identity is the private key, encoded as an nsec1... Bech32 string. 63 characters, starts with nsec1. Anyone who has this string has full control of the account.

You do not need to back up:

• The npub (derivable from the nsec)
• Your profile metadata (recoverable from relays as long as you can sign events)
• Your follow list (same)
• Your posts (they exist on relays even if you lose the key)

You do need to back up:

• The nsec. Just the nsec.

Everything else follows from having the nsec. Nothing follows from having the npub alone.

Option 1: Password manager

The default recommendation for almost every user.

What works: 1Password, Bitwarden, KeePassXC, Proton Pass, Dashlane, any password manager that encrypts your vault with a master password and stores only ciphertext on the provider's servers. Apple's iCloud Keychain qualifies too; it is end-to-end encrypted with your device passcode.

Setup (1Password example; the flow is equivalent in others):

1. Create a new item, category "Secure Note" or "Password."
2. Title it something unambiguous: Nostr nsec (alice@nostr.blog).
3. Paste the full nsec including the nsec1 prefix into the password field.
4. Save.
5. Verify the item is synced across your devices by opening 1Password on a second device and finding the same entry.

Why it works: The vault is encrypted with your master password before it leaves your device. The provider stores ciphertext and never has the plaintext. A breach of the provider leaks encrypted blobs, not your actual keys.

Why it can still fail: You forget the master password; you lose the account recovery (some managers have a recovery kit PDF you print, others do not); your device is compromised while the vault is unlocked and an attacker exports the items.

Fix for the weakness: Keep your master password somewhere physical and separate. Enable every recovery and 2FA option the password manager offers. Do not store the master password in a synced note.

Option 2: Paper backup

The most resilient option against digital failures. Works when everything electronic fails.

Setup:

1. Open a text editor and type the nsec exactly (or use the client's "export key" feature if available to generate a QR code).
2. Print to paper on a reliable printer. Do not screenshot; screenshots end up in cloud photos.
3. Write on the paper: the account name, the date, and (optional) where you backed it up.
4. Store in a location you physically trust: a home safe, a safety deposit box, a locked drawer. Not a notebook on your desk, not the first drawer anyone would open.

Why it works: A paper copy is not online. Nobody can exfiltrate it remotely. It survives losing your phone, your laptop, your cloud provider, and your internet access simultaneously.

Why it can fail: Water, fire, someone finding it. The standard fixes are a fireproof safe, a steel backup plate (the same ones Bitcoin seed-phrase users buy), or storing two copies in two physical locations.

Steel backup plates are an upgrade if the identity is high-value. They survive fire, water, and a decade of humidity. A basic plate costs around $20. You stamp the nsec into rows of metal with a punch. Overkill for most people, reasonable for a Nostr identity tied to real income.

Option 3: Hardware signer

The strongest option technically. Most complex to set up.

What it is: A device that holds the nsec and signs events remotely, without the nsec ever touching the client device. Your phone or laptop talks to the signer over a secure channel (Bluetooth, USB, or an encrypted relay subscription), sends it an event to sign, and gets the signed event back.

Options in 2026:

• Amber (Android) is a dedicated Nostr signer app that runs on a separate phone and receives sign requests over a local channel.
• Remote-signer "bunker" apps run somewhere you trust (your own server, a trusted device) and receive sign requests over Nostr itself using NIP-46.
• Hardware wallets with Nostr support (some Coldcard firmware, some Jade firmware, and dedicated projects like Seedsigner) can sign Nostr events as a side job.

Why it works: The nsec never leaves the signer. Even if your phone or laptop is fully compromised, the attacker cannot steal the key because they cannot access it. At most they can trick the signer into signing malicious events, but only while they have active connectivity.

Why it is hard: Setup is more involved than a password manager. You need a second device or a bunker deployment. Most mobile clients do not yet support remote signers as first-class citizens. Fewer users run this path, but the ones who do are the ones with the highest security needs.

Where not to save the nsec

Every option in this list has produced a support request that ended in "your account is gone." Avoid all of them.

• iCloud Notes. Apple stores the note content in a form they can read. Not end-to-end encrypted. A breach of iCloud means a breach of your Nostr identity.
• Google Keep. Same problem, with Google.
• Camera roll screenshots. The screenshot auto-syncs to iCloud Photos or Google Photos in plaintext. Even if you delete it from the phone, cloud providers often retain recent copies.
• Email drafts or self-emails. Your email provider can read draft and sent mail. If they get breached (and several major providers have, in the last decade), the nsec is in the leak.
• Telegram "Saved Messages" or any chat self-DM. Telegram's default chats are not end-to-end encrypted. Signal is better but not designed as a password backup.
• A plaintext file on Dropbox, Google Drive, iCloud Drive, OneDrive. The provider can read the file. A breach of the provider leaks your nsec.
• Your browser's built-in password manager if it is not E2E-encrypted. Check whether yours is. Safari iCloud Keychain is; some Chrome profile passwords are not unless you enable the on-device encryption setting.

The unifying rule: if the provider can, in principle, read the plaintext, do not store your nsec there. If the provider can only read ciphertext, the location is acceptable.

A realistic two-backup layout for most users

What we recommend if you want good but not paranoid security:

1. Password manager with the nsec as a Secure Note or Password item. Daily-use recovery path.
2. Paper backup printed and stored in a specific physical location. Disaster recovery.

Total setup time: ten minutes. Total recurring cost: zero. Total protection against routine key loss: very high.

For higher-stakes identities add:

• A second physical copy in a different location (a trusted family member's safe, a safety deposit box)
• A steel plate backup instead of paper
• A hardware or remote signer as the daily-use path, with the nsec backup reserved as emergency recovery

Mistakes that lose accounts, ranked by how common they are

From actual support threads across the Nostr ecosystem:

1. "I will back it up later." The single most common cause of permanent loss. The "later" does not arrive before the phone is wiped, lost, or upgraded.
2. Trusting one location. Phone in the pool, keychain reset after a security incident, password manager account locked out. Two copies in two different kinds of storage solves this.
3. Not labeling the backup. A password manager with 200 entries where one of them is an unlabeled "nsec1..." string is one failed search away from loss.
4. Using the npub where the nsec was needed. The user thinks they backed up but only saved the public half. Check that your backup starts with nsec1, not npub1.
5. Screenshots. One screenshot of the "account details" screen, auto-synced to a cloud provider, and the nsec is sitting in someone else's data center in plaintext.

Every one of these is a 30-second problem to prevent and a permanent problem to recover from. The asymmetry is the whole reason this article exists.