Privnote vs PrivateNote: Which One-Time Secret Service Should You Use?
Both encrypt in the browser. The difference is the key, the published design, and what happens if the wrong person gets the link.
Privnote popularised a useful idea: don’t paste a password, API key, recovery code, or confidential message directly into email or chat. Put it behind a temporary encrypted link, and destroy the stored payload after it has been read.
PrivateNote starts from the same idea and draws the security boundary in a different place.
Both services encrypt notes in the browser. The differences that matter are how the key is generated, how much of that design is published, what happens when the full link reaches the wrong person, and whether the sender can add stronger controls when the secret needs them.
PrivateNote publishes that client-side design, then adds controls when possession of the link is not enough: optional password protection, recipient verification on Starter and Business, encrypted files and media, and a CLI, editor extension, Chrome extension, or MCP so the secret does not have to be pasted into a page found through search.
Key takeaways
- Both encrypt in the browser. The differences are key generation, the published design, and what happens if the wrong person gets the link.
- PrivateNote uses a fresh 256-bit key and AES-256-GCM. Optional password protection — a password, passphrase, or PIN — wraps that key with Argon2id; it does not replace it.
- The full link is a bearer secret. Add password protection, or recipient verification on Starter and Business, when possession of the URL should not be enough.
- Self-destructing stops the stored payload from remaining available. It does not stop a recipient from copying what they were allowed to see.
Privnote vs PrivateNote at a glance
| Security property | Privnote | PrivateNote |
|---|---|---|
| Self-destructing notes | Yes | Yes |
| Recipient account required | No | No |
| Client-side encryption | Yes | Yes |
| Decryption secret kept out of the normal HTTP request | Yes | Yes |
| Documented 256-bit random encryption key | Not publicly documented | Yes |
| Documented AES-256-GCM encryption | Not publicly documented | Yes |
| Password protection | Yes | Yes — a password, passphrase, or PIN wraps the content key |
| Documented password-based KDF | Not publicly documented | Argon2id |
| Protection beyond possession of the full link | Password | Password, passphrase, or PIN; recipient verification on Starter and Business |
| Encrypted file attachments | Not currently offered | Yes |
| Photos, audio, and video | Not currently offered | Yes |
| Scheduled reveal | Not currently offered | Starter and Business |
| Open and destroy notifications | Yes | Yes, with a free account |
| Branded reveal pages | Not currently offered | Business |
| Developer tools (CLI, MCP, extensions) | Not currently offered | Yes |
| Third-party ads | Yes — Google Ads | No |
Comparison based on publicly available product information as of October 2026. “Not publicly documented” does not mean a mechanism is absent. It means the corresponding design could not be verified from Privnote’s public documentation. “Not currently offered” describes the product as documented today.
What Privnote gets right
Privnote addresses a real security problem.
If you paste a production password into email, Slack, Teams, or a ticket, the secret can remain there long after the person receiving it needed it.
A one-time link changes that. The channel carries a temporary URL rather than the plaintext secret. The recipient opens the URL, reads the note, and the stored payload can then be destroyed.
Privnote also encrypts notes in the browser. Its public documentation states that the decryption key is contained in the link, and that Privnote does not possess the complete link required to decrypt the stored note.
That is an important security property. Client-side encryption still answers only one part of the problem. OneTimeSecret vs PrivateNote covers a different case, where the service encrypts on its servers after the secret arrives as readable text.
Third-party ads
Privnote says Google Ads fund the service. Its privacy policy says third parties place cookies for commercial and promotional purposes. Ads shown to people in Europe are described as non-personalized.
PrivateNote does not show third-party ads and does not load advertising trackers. Aggregated first-party counts, such as notes created, stay with PrivateNote. They are not shared with advertising companies, and they do not include note content.
Client-side encryption is not the entire security model
A one-time-secret service has to answer at least three questions:
- Can the server read the plaintext?
- How difficult is it to recover the encryption key?
- What happens if somebody other than the intended recipient obtains the full link?
Browser-side encryption addresses the first question. Key generation addresses the second. Access controls address the third.
A service can accurately say that it encrypts in the browser and still make very different choices on the other two.
A strong cipher is only as strong as the secret protecting it
Modern symmetric cryptography is normally designed around security levels of at least 128 bits.
A strong cipher does not provide that level of security by itself if the secret protecting the ciphertext comes from a much smaller space.
Suppose an encryption system produces a 256-bit key from a random secret that contains only n bits of entropy. A key derivation function can turn that input into 256 output bits. It cannot manufacture the missing entropy.
Someone who knows the construction can search the original space of about 2ⁿ possibilities, rather than all 2²⁵⁶ possible output keys.
That is the difference between key length and key entropy.
The short-secret question with Privnote
Privnote’s public documentation states that the decryption key is contained in the note link.
It does not clearly document the current key-generation process, the entropy of the generated secret, or the resulting cryptographic security level.
That matters because the secret carried in the URL is part of the security boundary.
A short string is not automatically insecure. Its entropy depends on its alphabet, how it is generated, how it is distributed, and how it is used. Expanding a short random value into a longer encryption key does not increase that entropy.
The name of the cipher is not enough to conclude that a system provides 128-bit or 256-bit security. The whole key-generation process is what determines it.
PrivateNote makes this explicit
For a standard note, PrivateNote generates a fresh 256-bit cryptographically random encryption key locally for every note. That key is not a password, passphrase, or PIN, and it is not a short identifier stretched to 256 bits. It is the content key.
The browser encrypts the note with AES-256-GCM before upload. Only ciphertext is uploaded. TLS carries that ciphertext to PrivateNote’s Cloudflare worker.
The decryption key stays in the URL fragment, the part after #. For example, https://privatenote.ai/note/abc123#….
The browser handles the fragment. A normal HTTP request does not include it. The worker receives a note identifier and returns ciphertext. The recipient’s browser keeps the fragment and decrypts locally. How it works describes this split in more detail.
If you add password protection, that secret is separate. It can be a password, a passphrase, or a PIN. The note is already ciphertext. Argon2id derives a wrapping key from it on the device, and that wrapping key encrypts the content key. The fragment then holds the wrapped key. PrivateNote receives ciphertext, a salt, and the parameters the recipient’s browser needs. It does not receive that secret or the raw content key.
Published cryptographic design matters
“Encrypted” is a product claim. A cryptographic design should explain where keys are generated, which primitives are used, what reaches the server, and what remains on the client.
Privnote documents important high-level properties, including browser-side encryption and keeping the complete decryption link away from its server. Its public documentation does not clearly specify several lower-level details needed to evaluate the effective security level of the complete construction.
PrivateNote publishes those details so technical users can reason about the design rather than relying on the word “encrypted.”
Inspect the encryption design
See how PrivateNote generates keys, encrypts locally, and keeps the decryption key out of the server request.
The full link is a bearer secret
Strong encryption does not identify the person holding the key.
If Alice sends Bob a complete PrivateNote or Privnote link and Eve obtains that link first, Eve does not need to break AES-256. By obtaining the complete URL, she has obtained the capability needed to retrieve and decrypt the note.
This is the fundamental trade-off of a basic one-time link: possession of the complete URL can be sufficient for access.
For a low-risk handoff, that may be acceptable. For a production credential, client document, or recovery secret, you may want another control.
PrivateNote therefore lets the sender add password protection or, on Starter and Business, require recipient verification.
Password protection can be a password, a passphrase, or a PIN
Both Privnote and PrivateNote can add a second secret.
On PrivateNote, the sender chooses that secret. It might be a passphrase, a shorter password, or a PIN. It does not replace the content key. A wrong entry fails decryption on the device.
While it is being entered, PrivateNote shows a strength estimate, from very weak to very strong. It also checks whether that secret appears in known breaches. The check runs in the browser through Have I Been Pwned: only the first five characters of a SHA-1 hash are sent, not the password itself.
A password, passphrase, or PIN normally has far less entropy than the content key. Wrapping keeps that human secret from becoming the only secret in the construction.
Send it on a different channel from the link. If both arrive in the same compromised channel, the second layer collapses into the first. How to share a password securely covers the same rule.
Recipient verification changes the threat model
Sometimes a second shared secret is not what you need. The question may be whether the person opening the link is the person who was supposed to receive it.
On Starter and Business, PrivateNote can require recipient verification before revealing the encrypted payload. Stealing the URL, or receiving it by accident, is then not enough on its own.
That extra check is worth considering for:
- production credentials
- client documents
- employee information
- financial documents
- recovery information
- confidential legal material
A one-time Wi-Fi password may not justify the friction. A production credential might. The sender chooses. Verification is separate from optional password protection.
When the link alone isn’t enough
Add recipient verification to sensitive handoffs on Starter and Business.
Browser-based secret sharing has a phishing problem
A malicious clone does not need to break the encryption protocol. It can simply collect the plaintext before encryption happens.
Privnote’s popularity makes it an attractive target for lookalikes. People often reach it by searching rather than by opening a saved URL. A lookalike can copy the appearance and the workflow of a secret-sharing service and collect what the user types.
PrivateNote can be impersonated in the same way. Verify the domain before entering anything sensitive.
PrivateNote’s CLI, editor extension, Chrome extension, and MCP integration reduce reliance on search-engine navigation by letting technical users create encrypted handoffs from tools they already trust.
Create the handoff from tools you already trust
The PrivateNote CLI encrypts locally and returns the temporary link: npx privatenote-cli --expire 1h --output-url-only.
The CLI reads from stdin or a file, encrypts locally, uploads ciphertext, and returns the temporary URL. The secret therefore does not need to be pasted into a web page found through search.
The same model is available through PrivateNote’s editor extension, Chrome extension, and MCP.
Send a secret from your terminal
Encrypt locally and create a one-time link without opening the browser.
PrivateNote goes beyond text
Privnote currently focuses on text notes and does not offer encrypted file attachments. A text note stops being enough when the secret is not text. That includes:
- a confidential PDF
- an identity document
- a configuration file
- credentials together with supporting documents
- a photograph, an audio recording, or a short video
PrivateNote uses the same client-side encryption for files and media. Files are encrypted locally before upload. PrivateNote stores ciphertext. The recipient uses the secret in the link to decrypt. Sending sensitive documents walks through that handoff.
Sending files, photos, or recordings requires a free PrivateNote account, so storage and transfer limits can be enforced. Recipients still open the link without an account. After the first reveal, attachments remain available for a limited window. They do not become a long-lived shared folder.
One-time links solve a persistence problem
Suppose an administrator sends a production password through company chat. Even if the message was encrypted in transit, the plaintext password may still exist in:
- the sender’s history
- the recipient’s history
- synchronized devices
- search indexes
- workspace exports
- administrative retention systems and backups
A one-time link changes that. The conversation carries a temporary URL. The secret exists separately as ciphertext, and that stored payload does not need to remain available after the handoff. What a one-time secret link is explains the model.
Self-destructing does not mean impossible to copy
This limitation applies equally to Privnote and PrivateNote.
Once a recipient can see a secret, they can copy it, photograph the screen, write it down, or save information elsewhere.
Self-destruction controls the availability of the stored encrypted payload. It does not control what an authorized recipient does after opening it.
One-time links therefore reduce unnecessary persistence. They do not provide DRM for secrets.
Which should you choose?
Privnote may be enough if you only need a temporary text note, you want the simplest possible workflow, and you do not need file attachments or additional delivery controls. The service is funded by Google Ads.
Its public documentation leaves important details of the cryptographic construction unspecified. Unless you add its password option, possession of the complete link can be enough to open the note. It does not currently offer recipient verification for cases where the URL alone should not authorize access. A browser workflow also still depends on reaching the real site.
PrivateNote may be a better fit if you want a documented client-side design and the option to raise assurance when the secret needs it:
- a fresh 256-bit cryptographically random encryption key
- AES-256-GCM client-side encryption
- optional password protection — a password, passphrase, or PIN — that wraps the content key with Argon2id
- URL-fragment key separation
- recipient verification and scheduled reveal on Starter and Business
- encrypted files and media
- open and destroy notifications
- no third-party ads
- CLI, MCP, editor extension, and Chrome extension
The value of the secret should determine the level of assurance.
Frequently asked questions
Is PrivateNote an alternative to Privnote?
Yes. Both services share sensitive information through temporary encrypted links, and the recipient does not need an account. PrivateNote publishes the client-side design and adds encrypted files, recipient verification on Starter and Business, and developer tools when a basic link is not enough.
Does Privnote use client-side encryption?
Yes. Privnote states that notes are encrypted in the browser and that the decryption key is contained in the link rather than being available to Privnote’s server.
Is Privnote insecure?
That is too broad a conclusion. Privnote has meaningful security properties, including browser-side encryption. Its public documentation does not clearly specify enough of the current key-generation process to independently establish the effective security level of the complete construction.
Why does key entropy matter?
The nominal size of an encryption key does not necessarily tell you how difficult the original secret is to guess. If a 256-bit key is deterministically derived from a value with substantially less entropy, an attacker can enumerate the smaller input space. A key derivation function can derive a long key. It cannot create entropy that was not present in its input.
What cryptography does PrivateNote use?
The browser generates a fresh 256-bit cryptographically random encryption key locally and uses AES-256-GCM for authenticated encryption. Password-protected notes wrap that content key with Argon2id. The key, or the wrapped key, is carried in the URL fragment. See how PrivateNote encryption works.
What happens if someone steals a PrivateNote link?
Someone who obtains the complete URL has the capability needed to retrieve and decrypt an unprotected note. They do not need to break the encryption. For a higher-risk handoff, add password protection and send that secret on a different channel. On Starter and Business, recipient verification can make possession of the URL insufficient on its own.
Can Privnote send files?
Privnote currently focuses on text notes and does not offer encrypted file attachments. PrivateNote supports encrypted files and media as well as text. Sending files requires a free account. Opening the link does not.
Try the difference yourself
Create a client-side encrypted note with a fresh 256-bit key. No recipient account required.
Want to inspect the design first? See how encryption works
