Private Sharing vs Encrypted Sharing: What's the Real Difference?

You need to share a password or API key with someone. You Google "secure way to share secrets" and the top results are Privnote and OneTimeSecret. Both use words like "private" and "secure." Both self-destruct after reading. So they must be safe, right? Not exactly. The difference between "private" (access control) and "encrypted" (mathematically unreadable) is everything — and most tools get it wrong. Understanding this distinction is fundamental to making your notes truly private and secure.

What Most "Private" Sharing Tools Actually Do

Most secret sharing tools follow the same pattern, and it's not what their marketing implies. Here's what actually happens when you use Privnote or OneTimeSecret:

1. You type your secret into their website
2. Your plaintext secret travels to their server over HTTPS
3. Their server encrypts it using their own key and stores the ciphertext
4. You get a link. Recipient opens it. Their server decrypts and delivers the plaintext
5. Note is deleted after reading

Step 3 is the problem. The company's server receives your plaintext and holds the decryption key. "Private" here means only the person with the link can retrieve it — that's access control, not encryption. They can read it. Their employees can read it. A court order can compel them to hand it over. A breach can expose it.

Specific examples of what popular tools actually do:

• Privnote — encrypts server-side. Privnote's infrastructure processes your plaintext before storage. This is also why fake Privnote phishing sites (privnote.co, privnot.com) can intercept notes — server-side encryption can be replicated by any attacker who convinces you to use their lookalike site.
• OneTimeSecret — same model. Server-side encryption, they hold the key. The free tier limits expiry to 14 days. A legitimate service, but not zero-knowledge.
• Email / Slack / Teams — no encryption at all for the secret itself. Permanent record, searchable by admins, stored indefinitely on both parties' servers and devices.

What Zero-Knowledge Encrypted Sharing Actually Means

Client-side zero-knowledge encryption flips the model entirely. Instead of sending your secret to a server and trusting that server to encrypt it, your browser handles encryption before anything leaves your device.

1. Your browser generates a random encryption key locally
2. Your browser encrypts the secret — before anything is sent anywhere
3. The server receives only ciphertext — unreadable gibberish without the key
4. The decryption key is embedded in the URL fragment (the # part of the link)
5. Recipient opens the link — their browser decrypts locally

Why the URL Fragment Matters

When you share a link like encryptednote.com/view-note/abc123#DECRYPTIONKEY, the server only ever sees /view-note/abc123. It fetches the ciphertext and returns it. The #DECRYPTIONKEY part — the URL fragment — is never sent to the server. Browsers strip it before making the HTTP request. It stays entirely on the recipient's device and is used only for local decryption.

This is not a convention or a promise — it's how the HTTP protocol works. The fragment is defined in the URL spec as client-only. No server ever receives it.

What "Zero-Knowledge" Means in Practice

• Under a legal order, EncryptedNote cannot hand over readable content — the server never had the plaintext or the key
• In a data breach, attackers get only ciphertext they cannot decrypt without a key that was never stored server-side
• EncryptedNote's own team cannot read what you share — this is a technical guarantee, not a policy promise

Side-by-Side Comparison

⚠️ WhatsApp and iMessage encrypt the chat channel — but the secret you share lives permanently in both parties' chat history. WeChat/QQ use server-side encryption, meaning Tencent holds the key. None of these self-destruct.

Server-side encryption is better than no encryption — but it means the service can read your secret. Zero-knowledge means that's mathematically impossible.

Real-World Scenarios Where This Difference Matters

Sharing Passwords with a Contractor

With Privnote: your password travels to Privnote's servers as plaintext before it's encrypted. Privnote sees it. Their logs may record it. A breach of their infrastructure exposes it.

With EncryptedNote: your password is encrypted in your browser before anything is sent. The server receives only ciphertext — gibberish without a key it never has.

Sharing API Keys with a Developer

With OneTimeSecret: the API key is decryptable by OneTimeSecret under a legal order or in a breach. They hold the key. Their legal obligation is to comply with valid law enforcement requests.

With EncryptedNote: the API key is encrypted with XChaCha20-Poly1305 before leaving your browser. Even a court order cannot produce the plaintext — the server never had it.

When a Phishing Clone Attacks

Privnote has a well-documented phishing problem. Fake sites like privnote.co replicate Privnote's interface exactly — because server-side encryption can be mimicked. You type your secret into the fake site, it stores the plaintext and forwards a harmless encrypted version. The attacker reads your secret before you even know anything is wrong.

Client-side encryption cannot be intercepted this way. The encryption key is generated in your browser and embedded in the link you share. A phishing clone would receive only ciphertext it cannot decrypt — because it doesn't have the key that never left your browser.

How to Tell If a Sharing Tool Is Truly Encrypted

Before trusting any tool with a sensitive secret, ask these questions:

Frequently Asked Questions

Is Privnote actually private?

Partially. Privnote limits access to whoever has the link and deletes the note after reading — both useful features. However, Privnote encrypts on their servers, meaning their infrastructure processes your plaintext before storage. They technically can read your note before it's delivered. This is also why fake Privnote phishing sites can intercept secrets — server-side encryption can be replicated by any attacker with a convincing lookalike site. For truly sensitive information, a zero-knowledge tool where encryption happens in your browser is safer. See our full Privnote alternative comparison.

Is OneTimeSecret secure?

OneTimeSecret is a legitimate service that self-destructs secrets after reading — meaningfully better than email. However, it uses server-side encryption: their server holds the decryption key. Under a legal order or in a breach, the plaintext could be exposed. The free tier also limits expiry to 14 days. For zero-knowledge security where even the service provider cannot read your content, client-side encryption tools are the stronger choice.

What's the most secure way to share a password or API key?

Use a tool that encrypts in your browser before anything is sent. EncryptedNote uses XChaCha20-Poly1305 client-side encryption — the decryption key lives only in the URL fragment and never reaches our servers. The note self-destructs after reading. No account, no trace, no server-readable content at any point.

Can encrypted note sharing be intercepted?

With client-side zero-knowledge encryption, interception produces only ciphertext — mathematically useless without the key that never left the sender's browser. With server-side encryption (Privnote, OneTimeSecret), a compromised server or convincing phishing clone can intercept plaintext because the service holds the decryption key. The encryption location is everything.

What is XChaCha20-Poly1305 and why does it matter?

It's the encryption algorithm EncryptedNote uses — a modern authenticated encryption scheme with a 192-bit nonce that eliminates nonce-reuse vulnerabilities present in older algorithms. It's the same algorithm used by WireGuard VPN and is recommended by modern cryptographers. More importantly for you: it runs entirely in your browser, so the server never sees your plaintext. See our security page for the full technical breakdown.

Do I need an account to use encrypted note sharing?

Not with EncryptedNote. No signup, no email, no account — from either the sender or the recipient. Write your secret, get a link, share it. The note self-destructs after reading. Zero identity linked to the transaction.