Flowvault vs ProtectedText: an honest, technical head-to-head

ProtectedText has been the default answer to “is there a URL I can open, type a password, and start writing?” for over a decade. Flowvault is a newer project aimed at the same primitive, with a few specific technical choices that look different. This post is the honest head-to-head: what's the same, what Flowvault changes and why, where ProtectedText is genuinely better, and how to decide between them.

What's the same

Both products answer the same question: a zero-knowledge notepad you can open from any browser, with no account, no email, no software install. Both derive a key from your password with Argon2id. Both encrypt in the browser and send only ciphertext to the server. Both let you pick a URL and reuse it forever. That shared shape is why people compare them in the first place.

I have a lot of respect for ProtectedText. It's been running since around 2011, survived everything that's killed a dozen “encrypted pastebin” projects, and the fundamental UX — type a URL, type a password, write — is right. Flowvault wouldn't exist if ProtectedText hadn't shown that the shape works.

Four specific technical differences

There are four places where Flowvault and ProtectedText make different choices. Only the first two are concerns about ProtectedText itself; the other two are features Flowvault adds that ProtectedText doesn't have.

1. The legacy plaintext-password blob

This is the most specific, verifiable difference. Open a ProtectedText URL, watch the network tab on save, and you'll see it upload two ciphertexts: a modern blob keyed by an Argon2id-derived key, and an encryptedContentLegacyblob keyed directly by the raw password (for backwards compatibility with much older clients that didn't use Argon2).

The modern blob is fine. The legacy blob is the problem: if a database dump ever leaks, that second blob is crackable without doing any Argon2 work at all. A strong Argon2 parameter set multiplies the cost of a guess by several orders of magnitude. A legacy blob next to it reverts that protection.

Flowvault has no legacy compatibility layer because there aren't any older clients to be compatible with. Every ciphertext has to go through the full Argon2id chain to even attempt a decrypt.

2. Authenticated vs malleable cipher

ProtectedText's primary blob uses AES-256-CBC via the CryptoJS library. AES-CBC is not authenticated: if someone flips bits in the stored ciphertext, the client decrypts intosomething— possibly garbage, possibly just a mutated plaintext — without any signal that the ciphertext was tampered with.

AES-256-GCM, which Flowvault uses, is authenticated: any modification to the stored bytes produces a verification failure and the decrypt hard-aborts. For a threat model that includes an untrusted or compromised server, that matters. A malicious hosting provider could flip bytes in a CBC blob and you'd never notice until the content stopped making sense. GCM surfaces it immediately.

AES-GCM has been the default recommendation for authenticated encryption for about a decade now. There isn't a strong argument against using it in a 2026 notepad.

3. Plausible deniability (hidden volumes)

ProtectedText has one password per URL. You reveal the password, you reveal everything. If a border agent or adversary compels the password, there's no cryptographic alibi.

Flowvault implements VeraCrypt-style hidden volumes inside the browser notepad: one URL holds up to 64 independent notebooks, each behind a different password, and nobody can prove how many notebooks exist. Empty slots are filled with random bytes indistinguishable from real ciphertext. Under coercion you can reveal one password, show an ordinary- looking notebook, and not leave evidence of the others.

The full mechanism is in the hidden-volume deep-dive. No other browser-based encrypted notepad in 2026 offers this. It's the single biggest feature gap between Flowvault and ProtectedText.

4. Open-source scope

ProtectedText's client-side JavaScript is visible in the browser — you can read it on any page. That's better than most “encrypted” products. But the server side is explicitly closed source per their own FAQ. You can't verify what logging, retention, or rate-limiting happens server-side, and you can't self-host.

Flowvault is open end-to-end. The repository contains:

The frontend (Next.js, all of the crypto).
The Cloud Functions (the trusted-handover sweep, the Encrypted Send atomic counter, time-lock retention).
The Firestore security rules — the actual enforcement boundary between the operator and your data.

All three are deployed unmodified. You can read them, audit them, fork them, and self-host the whole thing on your own Firebase project. The zero-knowledge claim is falsifiable in a way ProtectedText's simply isn't.

Features Flowvault has that ProtectedText doesn't

Beyond the core notepad, Flowvault bundles four other zero-knowledge primitives that together replace a handful of separate products:

Multi-notebook tabs per password.Each password unlocks a workspace, not a single page. Rename, reorder, delete tabs — still one opaque blob on the server.
Trusted handover. Nominate a beneficiary with a separate password; if you stop checking in for an interval you configure, the vault auto-hands over. No account required for either party.
Time-locked notes. Encrypt a message that literally cannot be opened before a target date — not even by you — using drand and tlock IBE.
Encrypted Send. One-shot self-destructing links for sharing a password, an API key, or a recovery phrase. Key in the URL fragment, view cap enforced server-side by a Cloud Function.
.fvault encrypted backup + Markdown export. Download the full vault as a single zero-knowledge file, restore to any instance, or export the currently unlocked slot as plaintext Markdown for migration.

ProtectedText does none of these. If you need any of them, you're layering separate tools (Bitwarden Send for one-shots, a will for inheritance, etc.) on top.

Where ProtectedText wins

Honest scoring has to go both ways. There are real reasons to keep using ProtectedText.

Track record.ProtectedText has run for over a decade. Flowvault launched in 2026. If “still online in five years” is important to you, a 15-year- old service is a safer bet on base rates alone. (Mitigation in Flowvault: download a .fvault backup so you can restore on a self-hosted instance even if we disappear.)
Brand recognition.“Go to protectedtext.com” is a URL non-technical people remember. Flowvault is new and has to earn that familiarity.
Zero moving parts. ProtectedText is a static page and a blob store. Flowvault has Cloud Functions for the handover sweep, Encrypted Send atomicity, and time-lock retention. Fewer moving parts means fewer opportunities for bugs; this argument genuinely favours ProtectedText.
Simpler mental model if all you want is one notebook. If plausible deniability, inheritance, time-locks, and one-shot sharing are features you don't need and won't use, a product without them is simpler.
Stability-as-a-feature.ProtectedText hasn't changed much in years. For some use cases (“I just want the URL I saved in 2019 to keep working exactly the same”) that's a virtue.

Side-by-side

Flowvault vs ProtectedText

                                    Flowvault            ProtectedText

Account required                    no                   no
Password-to-key derivation          Argon2id             Argon2id
                                    (64 MiB, 3 iter)     (32 MiB, ~300 ms)
Cipher                              AES-256-GCM          AES-256-CBC
                                    (authenticated)      (unauthenticated)
Legacy plaintext-password blob      no                   yes
Plausible deniability               yes (hidden          no
                                    volumes, 64 slots)
Fixed-size ciphertext blob          yes                  no
Tamper detection on read            yes (GCM tag)        no
Multi-notebook tabs per password    yes                  no
Trusted handover to beneficiary     yes                  no
Time-locked notes (drand)           yes                  no
One-shot self-destructing sharing   yes (Send)           no
Encrypted backup / restore file     yes (.fvault)        no
Plaintext export                    yes (Markdown .zip)  manual copy
Open-source frontend                yes                  yes (client JS only)
Open-source server                  yes                  no
Open-source security rules          yes                  n/a (closed server)
Self-hostable                       yes                  no
Track record                        < 1 year             15+ years
Licensed                            MIT                  (unstated)

Migrating from ProtectedText

ProtectedText has no export function. The only way to move is manual: open the vault, copy each tab's plaintext, paste into Flowvault. A few practical notes if you're doing this:

Pick a Flowvault URL slug. It doesn't have to match your ProtectedText URL.
Set a strong password (different from your ProtectedText password; rotating during migration is a small free security upgrade).
Create a tab in Flowvault for each logical section of your ProtectedText notebook. Tabs are cheap; split by topic.
Open ProtectedText in one browser tab, Flowvault in another. Copy-paste section by section.
Once you're satisfied everything transferred, download a .fvaultbackup (Export menu) so you have a portable copy independent of Flowvault's servers.
If you used ProtectedText for shared-URL inheritance (“my spouse knows the URL and password”), now is a good moment to set up a trusted handover with a dedicated beneficiary password instead.

It takes about ten minutes for a typical notebook. You can keep the ProtectedText URL alive for a while as a fallback.

Who should pick which

Pick ProtectedText if

You're already using it and the URL is muscle memory.
You value a 15-year track record over a specific feature gap.
You have a single notebook, a strong password, and a threat model that doesn't include coercion or server compromise.
You don't need tabs, inheritance, time-locks, or backups.

Pick Flowvault if

You want plausible deniability — one URL, multiple notebooks, different passwords.
You want modern authenticated encryption (AES-GCM) and no legacy password-keyed blob sitting next to your data.
You want a beneficiary to be able to open the notebook if you stop checking in.
You want the one-shot send, the time-lock, or the encrypted backup as part of the same tool instead of three separate ones.
You want the option to self-host, read the server code, or fork the project.

TL;DR

Flowvault is an honest upgrade on the ProtectedText primitive: same URL-and-password shape, better crypto defaults (no legacy plaintext-password blob, AES-GCM instead of CBC), a deniability feature that doesn't exist in ProtectedText, and a server side that's actually open and self-hostable. ProtectedText's main remaining advantage is its longevity.

If you're weighing them, the best test is to open both and use them for a week. Flowvault URLs are free. Try it at flowvault.flowdesk.tech, write some notes, add a decoy password, download a backup, and decide from experience rather than a spec sheet.