---
title: "Encrypted Notes App: How to Keep Cloud Markdown Truly Private"
description: "Choosing an encrypted notes app? What zero-knowledge really means, how the top private-notes tools compare, and how to keep your cloud markdown truly private."
author: "MDflow"
date: 2026-07-14
reading_time: "12 min"
canonical_url: https://mdflow.cz/blog/encrypted-notes-app
md_url: https://mdflow.cz/blog/encrypted-notes-app.md
---

# Encrypted Notes App: How to Keep Cloud Markdown Truly Private

*Published July 14, 2026 · 12 min read*


Picking an **encrypted notes app** used to be a niche decision for the security-obsessed. In 2026 it is a mainstream one, because the notes you keep online are no longer just yours to read — they are the context you hand to AI agents, the drafts you sync across devices, and the secrets you would never want surfacing in a breach disclosure. The question is no longer *should* your notes be encrypted, but *which* app keeps your cloud markdown **truly private** without making it useless.

This is a decision-stage guide. If you want the deep mechanics of *how* client-side encryption works, we wrote a [full explainer on client-side encryption](/blog/client-side-encryption-for-online-notes). Here, the goal is narrower and more practical: what to look for, how the leading private-notes tools actually compare, and how to set up a workspace where the notes you want secret stay server-blind while the rest stays useful.

> **TL;DR** — A truly private notes app encrypts your content on *your* device before upload, so the provider stores only ciphertext (this is "zero-knowledge" or client-side encryption). The strong options in 2026 are Standard Notes, Notesnook, Joplin, and Obsidian — but most encrypt *everything*, which locks AI agents out entirely. [MDflow](/) takes a different line: per-document AES-256 encryption in your browser, free on every plan, with an open-source [command-line tool](https://www.npmjs.com/package/mdflow-crypt) so you can decrypt your notes locally and never get locked in — and everything you *don't* encrypt stays readable by your AI agents.

## What "truly private" actually means

A notes app is truly private only when the provider **cannot read your notes even if it wanted to**. That is a higher bar than most apps clear, and the marketing rarely makes the difference obvious. Three terms matter:

- **Encryption at rest** — the provider encrypts your data on its disks but *holds the keys*. This protects against a stolen hard drive. It does **not** protect against a database breach, a rogue insider, or a subpoena, because the provider can decrypt your content at will. Most mainstream note apps stop here.
- **Client-side (end-to-end) encryption** — your device encrypts the note *before* it is uploaded, and decrypts it *after* download. The server only ever handles ciphertext. This is the bar "truly private" requires.
- **Zero-knowledge** — the *result* of doing client-side encryption properly: the provider has zero knowledge of your keys or your plaintext. There is simply no readable copy on the server to leak.

There is one honest ceiling worth stating up front, because vendors rarely do: in a *web* app, the same server that stores your ciphertext also delivers the JavaScript that encrypts it, so browser-based client-side encryption is strongest as a defense against a breach of *stored* data — a leaked database, a stolen backup, an over-retentive log. That is the threat that actually befalls people, and it is the one zero-knowledge encryption removes completely. (Native apps and open-source, auditable clients raise that ceiling.)

## What to look for in an encrypted notes app

Before comparing products, know your checklist. A genuinely private notes app should tick most of these:

1. **Client-side / zero-knowledge encryption**, not just "encrypted at rest." Look for the explicit claim that the provider never sees your plaintext or your keys.
2. **A named, modern cipher.** AES-256-GCM or XChaCha20-Poly1305 for the content, and a slow key-derivation function (PBKDF2 with a high iteration count, or Argon2/scrypt) so your password is expensive to brute-force.
3. **Open, portable format.** Can you get your notes *out* as plain files if the company disappears? Markdown-native beats a proprietary database with a lossy "export" button.
4. **No-recovery honesty.** True zero-knowledge means the provider *cannot* reset your password — so a real one will warn you there is no recovery. An app that can email you your notes back is not zero-knowledge.
5. **Cross-device access** without you running a server, if convenience matters.
6. **A clear stance on AI/agent access** — because, as we'll see, encryption and agent-readability are mutually exclusive per note. The best tools let you decide document by document.

## The encrypted notes app landscape in 2026

Here is an honest map of the strong options, and where each one fits. All of these do real client-side encryption — the differences are in *scope*, *format*, and *whether AI can still use your notes*.

| App | Encryption | Markdown | Hosted / self-host | Granularity | AI-agent access |
|---|---|---|---|---|---|
| **Standard Notes** | E2EE by default (XChaCha20-Poly1305) | Paid plan only | Hosted or self-host | Everything encrypted | None (all ciphertext) |
| **Notesnook** | Zero-knowledge by default | Yes | Hosted or self-host | Everything encrypted | None (all ciphertext) |
| **Joplin** | Optional E2EE sync | Native | Bring-your-own sync | Everything (if E2EE on) | Local only |
| **Obsidian** | Local vault; paid E2EE Sync | Native (files on disk) | Local-first | Whole vault | Local plugins only |
| **MDflow** | Optional client-side AES-256 | Native | Hosted | **Per-document** | **Unencrypted docs, via MCP + API** |

A few notes on each:

- **[Standard Notes](https://standardnotes.com/)** is the veteran privacy-first choice. Everything — notes, tags, metadata — is end-to-end encrypted by default, on unlimited devices, free. The catch for markdown people: the free plan is plain-text only; markdown and rich editors require the paid Productivity plan. Because *everything* is encrypted, no external AI agent can read any of it.
- **[Notesnook](https://notesnook.com/)** is the modern open-source contender: zero-knowledge by default, markdown support, a clean interface, and self-hostable. Same structural tradeoff — encrypt-everything means no agent can read your notes over the network.
- **[Joplin](https://joplinapp.org/)** is the power-user's open-source pick: markdown-native, with optional end-to-end encrypted sync where *you* choose the target (Nextcloud, WebDAV, S3, local). Maximum control, more setup, and its AI/agent story is local plugins rather than a hosted API.
- **[Obsidian](https://obsidian.md/)** isn't an "encrypted app" per se — it's a local-first markdown vault on your own disk (private by default because nothing leaves your machine). Add the paid Obsidian Sync for end-to-end encrypted cross-device sync. Agent access is community plugins running locally, which the ChatGPT web app and your phone can't reach.

The pattern is clear: every strong encrypted notes app encrypts **all or nothing**. That is exactly right if your only goal is secrecy — and exactly wrong the moment you want an AI agent to *use* your notes.

## The gap: encryption vs. AI-readability

Here is the tension almost every encrypted notes app leaves unresolved. **An AI agent can only use what the server can read.** If your notes are zero-knowledge encrypted, the server sees ciphertext, so ChatGPT, Claude, Cursor, or Codex — connecting over an API or a [Model Context Protocol (MCP)](/docs/mcp) server — see ciphertext too. Encryption and agent access are, correctly, *mutually exclusive per note*.

Most apps force this as a global switch: turn encryption on and lock your agents out of everything, or leave it off and hand the provider your plaintext. But that's a false choice. The right unit of decision is **the individual document**:

- Your API keys, health records, legal drafts, and private journal → encrypt them; no one, not even your own agents, should read them.
- Your project notes, research, meeting summaries, and reference docs → leave them readable, so your AI can retrieve them as context.

The best setup lets you draw that line document by document. That is the wedge MDflow was built around.

## How MDflow keeps your cloud markdown truly private

MDflow is a hosted markdown workspace where the documents you want private never reach the server as plaintext — while the documents you want agents to use stay fully readable. Here is how to actually do it, and why it stays portable.

### Encrypt a document in your browser (30 seconds)

1. Open any document in the MDflow editor.
2. Choose **Encrypt**, and set a password. Save that password in a password manager — **there is no recovery.**
3. MDflow encrypts the document's markdown body **in your browser** with **AES-256-GCM**, using a 256-bit key derived from your password via **PBKDF2-HMAC-SHA-256 at 600,000 iterations** ([OWASP's current recommendation](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)). Every save uses a fresh random IV.
4. Only the ciphertext travels to the server, stored as a self-describing marker:

```text
mdflow-enc:v1:5oF3a2t...long-base64url-blob...kQ
```

The server treats it as an opaque string — it never receives your password and never sees your text. Your document title and folder names stay readable so you can still organize and find your files; only the body is encrypted. Unlock once per device and the derived key (not the password) is cached until you hit **Lock**.

### You're not locked in: decrypt locally with `mdflow-crypt`

This is the part that separates "trust us" from *truly* private. MDflow's encryption format is open and documented, and there's a zero-dependency, open-source command-line tool — [`mdflow-crypt`](https://www.npmjs.com/package/mdflow-crypt) — that does the exact same crypto on your own machine. Your plaintext and password never leave your computer, and never go to a server or an AI model:

```bash
# Decrypt an exported mdflow-enc:v1 file locally → notes_decrypted.md
npx mdflow-crypt decrypt notes.md

# Encrypt locally, then paste the result into MDflow → notes_encrypted.md
npx mdflow-crypt encrypt notes.md
```

It uses the identical scheme — `PBKDF2-HMAC-SHA256` (600k iterations) → `AES-256-GCM` — so a note encrypted in the browser opens on your laptop and vice versa. If MDflow ever vanished tomorrow, you could still read every encrypted note you own with an MIT-licensed tool that fits in one file. That is what "no lock-in" should mean.

### The deliberate line between private and agent-ready

Because an encrypted document is unreadable to the server, MDflow **excludes it from search** and returns it only as opaque ciphertext through the [HTTP API](/docs/api) and the [MCP server](/docs/mcp). Everything you *leave* unencrypted stays fully agent-ready: MDflow's folders, [folder descriptions](/markdown-ai), and the `mdflow_get_context` tool make that context easy for ChatGPT, Claude, Cursor, and Codex to retrieve and write back. You decide where the line falls, one document at a time — the choice the all-or-nothing apps don't give you.

And notably, **encryption is free.** It's on every MDflow plan, not gated behind Pro — alongside public and private sharing, [collections](/faq), comments, and automatic version history.

### Where MDflow is headed

This is **direction, not a dated commitment**, but the shape of our thinking on privacy:

- **More metadata protected over time.** Body-only encryption is the honest start; extending protection to more fields is a direction we care about — and one we'd rather under-promise than overstate.
- **Encrypted sharing that stays server-blind.** Today you can share an encrypted document behind a password gate that decrypts in the reader's browser; making that flow smoother is on the list.
- **One-click OAuth for agents.** Connecting an agent today means creating a Personal Access Token; native OAuth for the ChatGPT app and Claude.ai on the web is on the way, so your *unencrypted* context connects with a single authorize-and-go.

## The bottom line

A truly private notes app is one where the provider only ever holds ciphertext — that's the difference between "we encrypt your data" (they hold the keys) and zero-knowledge (only you do). Standard Notes, Notesnook, Joplin, and Obsidian all clear that bar for pure secrecy, and any of them is a fine choice if you never want an AI to touch your notes.

MDflow is for the increasingly common case in between: you want *some* notes truly private and *some* notes readable by your agents, on one hosted markdown workspace, with the freedom to walk away — per-document AES-256 encryption in your browser, free on every plan, and an open-source [`mdflow-crypt`](https://www.npmjs.com/package/mdflow-crypt) tool so your encrypted notes are yours to decrypt anywhere.

[Start free](/login) · [Connect an AI agent](/docs/mcp) · [Read the API docs](/docs/api)

## Frequently asked questions

### What is the best encrypted notes app in 2026?

There is no single best — it depends on your priority. Standard Notes and Notesnook are strong zero-knowledge choices that encrypt everything by default. Joplin is best if you want open-source with your own sync target. Obsidian suits local-first users who add paid end-to-end encrypted Sync. MDflow fits people who want per-document encryption on a hosted markdown workspace that AI agents can also read — you choose which notes are encrypted and which stay agent-readable, and it is free on every plan.

### What does zero-knowledge mean for a notes app?

Zero-knowledge means the provider has zero knowledge of your keys or your plaintext. Your notes are encrypted on your own device before upload, so the server only ever stores ciphertext it cannot read. Even a database breach, a rogue insider, or a legal demand cannot reveal content the provider never held in readable form. It is the result of client-side (end-to-end) encryption.

### Can I keep cloud notes private without self-hosting?

Yes. Client-side encryption lets you keep the convenience of a hosted cloud app while the provider stores only ciphertext. You get close to self-hosted-grade secrecy — no server to patch, back up, or secure — because the plaintext never leaves your device. For the documents that matter, you draw the privacy line without becoming your own sysadmin.

### Are encrypted notes readable by AI like ChatGPT or Claude?

No, and that is the point. If a note is encrypted client-side, the server only sees ciphertext, so an AI agent connected through an API or MCP server cannot read it either. This is why all-or-nothing encryption conflicts with AI workflows. MDflow makes encryption per-document: encrypt the secrets you want no one (including your agents) to read, and leave the context you want agents to use unencrypted.

### How does MDflow keep markdown notes private?

MDflow encrypts a document's markdown body in your browser with AES-256-GCM, using a key derived from your password with PBKDF2-HMAC-SHA-256 at 600,000 iterations. The server only ever stores ciphertext (`mdflow-enc:v1:…`) and never sees your text or password. You can also decrypt any encrypted document locally with the open-source `mdflow-crypt` command-line tool, so you are never locked in. Encryption is free on every plan, and there is no recovery — save your password in a password manager.

## Further reading

- MDflow — [Client-Side Encryption for Notes You Store Online](/blog/client-side-encryption-for-online-notes) (the deep how-it-works explainer)
- OWASP — [Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) (PBKDF2 iteration guidance)
- OWASP — [Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)
- MDN Web Docs — [Web Crypto API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API)
- npm — [`mdflow-crypt`](https://www.npmjs.com/package/mdflow-crypt) (the local decrypt/encrypt CLI)
- MDflow — [Markdown for AI agents](/markdown-ai) · [MCP documentation](/docs/mcp) · [API documentation](/docs/api) · [FAQ](/faq)