Encrypted Send vs Bitwarden Send vs Privnote: account-less one-shot secrets compared

If you just want to hand someone a password, an API key, or a recovery phrase once, which one-shot link service should you reach for? This post compares the six obvious candidates in 2026 — Flowvault Encrypted Send, Bitwarden Send, Privnote, OneTimeSecret, PrivateBin, and 1Password Share — with specifics about key location, view-cap enforcement, open-source posture, and the trade-offs behind each choice.

What a “one-shot secret link” actually needs to do

Before the head-to-head, the criteria. A service in this category is really answering four questions:

Where does the decryption key live? Ideally in the URL fragment (#), which the browser never sends to the server.
Who enforces the view cap? The server has to, otherwise a malicious recipient can just curl the link twice. That means the server mediates reads and strictly counts.
Is the code verifiable? Open-source client + open-source server means you can audit the claim. Open-source client alone is partial.
Can a second factor (a password) protect the link? If your channel gets scraped, the link alone shouldn't be enough.

Let's evaluate the six candidates against those four axes.

Flowvault Encrypted Send

The /send/new page in Flowvault. Full behaviour:

A random 256-bit AES-GCM key is generated client-side. The plaintext is encrypted in the browser; only the ciphertext is uploaded.
The URL is flowvault.flowdesk.tech/send/<id>#k=<base64url-key>. The key lives after the #, so it never reaches Flowvault's server in any HTTP request.
Optional password layer. If enabled, the plaintext is double-wrapped: Argon2id-derived password key inside, AES-GCM outside. The password travels in a different channel from the URL.
View cap is enforced by a Cloud Function in a Firestore transaction: decrement counter, return ciphertext only if the decrement succeeded, hard-delete the doc when the counter hits zero. The security rules deny direct client reads of the send document — the only read path is through the atomic function.
Default lifetime 24 h, max 30 days. Hourly Cloud Function sweeps expired docs.
Max payload 128 KiB plaintext. Plenty for secrets, not intended for file transfer.
All three layers — frontend, Cloud Function, Firestore rules — are in one repo. Self-hostable.

No account, ever. No email. No rate-limit that requires one.

Bitwarden Send

Bitwarden Send is Bitwarden's first-party take. Mature, widely used, solid engineering.

Account required to create.You need a Bitwarden account to create a Send link (free tier works for text, paid for files). This is the biggest difference: if you already have Bitwarden, it's convenient; if you don't, it's a signup barrier.
Key in URL fragment, same as Flowvault.
View cap and expiry enforced server-side. Password layer available.
Open-source clients and server. Self-hostable via Vaultwarden or the official server.
Payload limits tied to your plan (free: 100 MB for files, practically unlimited for text).

If you're already a Bitwarden user, Send is the natural choice for one-offs. The account requirement is the trade-off.

Privnote

Privnote is the historical original of this category (2008). Simple shape: paste text, get a URL, link self-destructs on first read.

Key in URL fragment. Plaintext is never sent to the server.
View cap is 1 (fixed); expiry is up to 30 days or “read immediately.”
Optional password layer, optional email notification of read.
Closed-source server.The client-side JS is available to inspect but the backend is proprietary. You can't self-host.
Free tier is ad-supported.
Used more-or-less as a household name, which is its own usability advantage (“go to privnote.com” needs no explanation).

Great default for casual, very-short-lived secrets. If your threat model includes the operator, the closed-server posture matters.

OneTimeSecret

OneTimeSecretis the archetype of the “account-less privnote clone” genre.

No account needed. Paste, get a link, done.
Key is typically in the URL path (not fragment) on the hosted version; self-hosted builds can vary. This means the hosted operator could see the key, as a matter of design.
Optional passphrase layer is server-side Argon2 — the passphrase hash reaches the server and is used to gate the read.
Open-source server and client. Self-hostable, which is the main reason to use it.
Widely self-hosted by companies that want a private alternative.

If you self-host OneTimeSecret behind your VPN, it's an excellent fit for an internal tool. On the public instance, the key-in-URL design means you're trusting the operator with more than Flowvault does.

PrivateBin

PrivateBin is a pastebin with client-side AES-256 and zero-knowledge semantics, forked from ZeroBin many years ago. Many instances exist in the wild (cryptgeon, snopyta, etc.).

Client-side encryption with key in URL fragment.
Configurable view cap (burn after reading) and expiry.
Optional password on top.
Open-source end-to-end. Many public instances, though their trust posture varies.
Supports Markdown and code, plus rudimentary Tor/Onion deployments.

The closest non-Flowvault equivalent by philosophy. If you want a pastebin more than a note sharer, PrivateBin is a good pick.

1Password Share

1Password Share generates a link from an item in your 1Password vault.

Requires a 1Password account to create.
Key management is internal to 1Password's mediated sharing; the recipient doesn't need an account to open.
Expiry + one-time-view enforced by 1Password's infrastructure.
Closed-source server. Open-source client would be stretching the term.
The best UX for existing 1Password users because it reaches directly into your vault.

If you're already paying for 1Password, this is the frictionless option. If not, you're paying a subscription for a feature that's free elsewhere, with a closed-source server in the mix.

Side-by-side

Feature comparison

                            Flowvault   Bitwarden   Privnote   OneTime-   Private-   1Password
                            Send        Send                   Secret     Bin        Share

Account required            no          yes         no         no         no         yes
Free / paid                 free        free tier   free       free       free       paid
Key in URL fragment         yes         yes         yes        no*        yes        n/a
Server enforces view cap    yes         yes         yes        yes        yes        yes
Open-source frontend        yes         yes         partial    yes        yes        no
Open-source server          yes         yes         no         yes        yes        no
Self-hostable               yes         yes         no         yes        yes        no
Password gate (2nd layer)   yes         yes         yes        yes        yes        no
Default view cap            1           configurable 1          1          configurable 1
Max lifetime                30 d        30 d        30 d       7 d        configurable 30 d
Max plaintext payload       128 KiB     ~5 MB       very small large      large      ~vault item

(* OneTimeSecret hosted version: key is part of the URL path,
   not the fragment. Self-hosted builds may be configured differently.)

How to actually choose

The right service depends on three questions. If I were writing a cheat sheet for a friend, it would look like this.

For the casual send-a-password case

Anybody here is fine. Privnote is the most recognisable name; Flowvault Encrypted Send, Bitwarden Send, PrivateBin, OneTimeSecret all do the job.

If you're already in one of these ecosystems

Use Bitwarden Send (if Bitwarden user) or 1Password Share (if 1Password user). The in-vault integration is a real UX win for frequent senders.

For the paranoid case

You want the key to definitely never touch a server, you want to audit the mediator code, you want a password layer in front, and you want the option to self-host. That narrows to Flowvault Encrypted Send, Bitwarden Send self-hosted, and PrivateBin self-hosted. All three are reasonable; Flowvault adds the benefit of being in the same ecosystem as a persistent notepad with hidden volumes and time-locks, so one URL covers most secret-handling needs.

For large file transfer

Use Bitwarden Send (up to 100 MB free, 500 MB paid) or Firefox Send alternatives (Hat.sh, OnionShare). Flowvault, Privnote, and PrivateBin are text-sized.

Four things people get wrong about this category

“The link already expired/opened” is a feature, not a bug. If your recipient says “the link says it's been opened,” assume someone else opened it and the secret is burned. Rotate immediately, don't try to reopen.
Share the link and the password separately. If both travel over the same channel, the password adds no real protection.
Chat apps preview links. Some (Slack, Discord, certain email scanners) open URLs to generate previews. If your service uses view cap 1, the preview counts as the view. Favour passwords or longer caps when sending into these channels, or use a service that detects bots (Flowvault, Bitwarden Send, Privnote all treat GET requests carefully but none is immune to aggressive previewers).
Fragments aren't magic. They protect against the serverseeing the key. They don't protect against a shoulder surfer, a compromised browser, or a malicious extension. The URL itself is always sensitive.