Should You Share a Crypto Seed Phrase Through a One-Time Link?

Before encryption, ask: does the phrase need to leave where it is? Often, no.

• Metal backup — stored in a safe or safety deposit box
• SLIP-39 — or similar schemes for inheritance or disaster recovery
• Hardware wallet transfer — when practical, instead of the recovery phrase

Every transmission adds a chance of disclosure. If you can avoid sending it, do. For other channels that also retain secrets indefinitely, see why email is the worst place for secrets.

A seed phrase is the root secret for an entire digital estate—not “just another password.”

Unlike most credentials, it:

• Grants full control — over assets
• Often lasts decades — without rotation
• Cannot be changed — if compromised
• Has no vendor recovery — if stolen

You are not only defending against today's attackers—you are making choices that may matter ten or twenty years from now.

PrivateNote encrypts in your browser before upload. Our servers see ciphertext only; the key never reaches us. That is far better than email, chat, or cloud docs for everyday secrets—and aligns with a strict end-to-end encryption model for the note contents.

Every browser crypto app shares one constraint: plaintext must exist in the browser before encryption. Malicious JavaScript—from extensions, supply-chain compromise, injection, or a bad CDN—could theoretically read it first. That is inherent to client-side encryption in the browser, not unique to PrivateNote.

For API keys and temp passwords, that trade-off is usually fine. For a seed phrase protecting life savings, you may want to trust fewer systems.

Encrypt locally, then upload ciphertext only:

Seed phrase
     │
     ▼
Local encryption (age / GnuPG / OpenSSL)
     │
     ▼
Encrypted ciphertext
     │
     ▼
PrivateNote

PrivateNote never receives the mnemonic—only encrypted data.

• age (recommended for most users): simple file encryption with secure defaults — github.com/FiloSottile/age
• GnuPG: excellent if you already use OpenPGP.
• OpenSSL: trusted and powerful; low-level CLI—better for experienced users.

# Install age (pick your platform)
# macOS:        brew install age
# Windows:      winget install FiloSottile.age
# Linux (apt):  sudo apt install age

age --version

age -p -o seed.txt.age seed.txt    # encrypt with passphrase
age -d -o seed.txt seed.txt.age    # decrypt on a trusted machine

After seed.txt.age is verified, securely erase plaintext on the sender's device. After the recipient imports into a wallet, erase their plaintext copy too.

For regular exchange with someone, age -r (public-key mode) avoids a shared passphrase—worth learning separately.

Docs: age · GnuPG · OpenSSL

Split the encrypted file from the secret that unlocks it. You are separating the .age ciphertext from the age decryption passphrase—not sending the seed phrase mnemonic through a second channel.

1. Upload the encrypted file (ciphertext) with PrivateNote
2. Send the age passphrase that decrypts that file—via Signal, phone, or in person

An attacker must compromise multiple systems—not one link.

The split is really about replaceable versus long-lived master secrets—not the file format or channel alone.

For API keys specifically, see our guide on how to share an API key securely.

Every approach has trust assumptions—password managers, hardware wallets, offline tools, browser crypto. None is perfect; trade-offs differ. The question is whether they fit the value of what you protect.

We built PrivateNote so encryption happens before data reaches our servers. For temporary, replaceable secrets, that beats email, messaging, or cloud storage. You can also send a secret without an account. Read how PrivateNote works for the full model.

For a seed phrase that could be your life savings:

• avoid transmitting when you can
• encrypt locally
• upload ciphertext only
• erase temporary plaintext
• send the age file passphrase—not the mnemonic—on a separate channel when possible