End-to-end encrypted notes: what the server can and can't see

What is end-to-end encryption, when the only person reading your notes is you? It means your notes are locked on your own device before they go anywhere, and only your devices hold the key that unlocks them. The company that stores and syncs your notes keeps scrambled data it cannot read, although it still sees some facts about that data, such as how big it is and when it changed.

This guide explains end-to-end encrypted notes in plain words: how they differ from the "encrypted" labels you see everywhere, what a stored note actually looks like on a server, and what the server can and can't see. We use Cappa, the notes app we build, as the worked example, including the parts that are not perfect.

What is end-to-end encryption?

Encryption turns readable text into what looks like random noise, using a secret number called a key. With the right key, the noise turns back into your text. Without it, the data is useless.

"End-to-end" says where the locking and unlocking happen: only at the ends. For a messaging app, the ends are the sender and the recipient. For a notes app, both ends are usually you: your laptop today, your phone tomorrow. Everything in between (your Wi-Fi, the internet, the company's servers, its backups) only ever handles the locked version.

Most explanations of end-to-end encryption are about chat apps, where the hard part is getting a key to another person safely. Private notes are simpler in one way and harder in another. There is no other person, so no key exchange. But you still need the same key on every device you own, without ever handing it to the company in the middle.

Most note apps that do this, Cappa included, solve that problem the same way: they derive the key from a password only you know. Every device that knows the password can rebuild the key by itself. The server never needs to be trusted with it.

Encryption in transit, at rest and end to end

"Your data is encrypted" can mean three very different things. The question that separates them is always the same: who holds the key?

Encryption in transit

Protection while data travels across a network, usually HTTPS (the padlock in your browser). It stops someone on the same café Wi-Fi from reading your traffic. The connection is decrypted when it reaches the company's servers.

Encryption at rest

Protection for data stored on the company's disks and backups. It helps if a disk is stolen or thrown away. The company holds the key, because its software decrypts your data every time it shows it to you.

End-to-end encryption

Data is encrypted on your device and decrypted only on your devices. The company stores and forwards it but never holds the key.

Most apps use the first two, and they are genuinely useful. But notice that in both cases the company can still read everything. That is not a flaw in their encryption. It is how those kinds of encryption are designed to work.

HTTPS also often ends before your data reaches the company's own computers. Many services sit behind a content delivery network or proxy that decrypts the connection first. Cappa's traffic, for example, goes through Cloudflare, so HTTPS ends at Cloudflare's edge. With end-to-end encryption that matters less, because the notes inside the connection are already encrypted. The Electronic Frontier Foundation draws the same line for messaging: with transport-only encryption, the provider in the middle "can see unencrypted copies of your messages."

What encryption does to a note

The interactive box below uses the same kind of encryption Cappa uses for notes, AES-256-GCM, running inside your browser. It creates a random key in this tab, encrypts whatever you type, and shows you what a server would receive. Nothing you type is sent anywhere.

Try three things:

• Encrypt the same text twice. The result changes every time. Each encryption uses a fresh random number called a nonce (a "number used once"), so identical notes never produce identical ciphertext. Someone watching the server can't tell that two notes say the same thing.
• Look at the sizes. The encrypted version is 16 bytes longer than your text. Those 16 bytes are the authentication tag, a seal computed from the key and the content.
• Change one byte. Decryption is refused. The tag no longer matches, so tampering is detected instead of producing corrupted text.

That last property is why modern apps use "authenticated" encryption, which protects secrecy and integrity together. If you want to understand how AES and GCM mode do this without the math, read AES-256-GCM explained without math. The formal definition is in NIST SP 800-38D.

What a stored note looks like on the server

Here is one note as a row in Cappa's database, simplified. The outer box is what the server can read. The inner box is what it stores but cannot open.

Row in the encrypted records tablereadable by the server

record id: 7f3c9a2e-…type: notesize: 1,284 bytesrevision: 12created: 2026-09-02 08:14 UTCupdated: 2026-09-27 21:40 UTC

Encrypted noteopens only with your vault key

nonce: 12 random bytes

THENf9rDy5bxDkZRk0B3LXDjoOCG2BzIXDcWHtkDCikZ_TQFxOgfoQJeMaDMDfeMNeIGeRhiCYeleDrbvy5eydKDxzaIPXe_-UKcyiYGrccL0RBwl04ZiQMELYQfB0P0sEYJVY2z0ui30Rf8SSFgQhIJbceWmuVjRnLvkYJwkQ_Y2C_LPmUX

Inside: the title, the text, tags, attachments and images, pinned and archived state, and your own created and edited dates.

Each label tells the server something:

• Record id is a random identifier made on your device. It links versions of the same note, but it says nothing about the content.
• Type is either note or the single record that holds your app preferences.
• Size is the length of the ciphertext. It roughly reveals how long a note is. A note with a photo in it is visibly larger than a shopping list.
• Revision counts saved versions, so the server can refuse a stale write from an old device.
• Timestamps show when the server received the note and each change. A deleted note leaves a small marker (a "tombstone") with no ciphertext, so other devices know to remove it.

The ciphertext is also bound to its label. Cappa encrypts each note together with its vault, record id, type and revision as "additional data." If a server swapped one note's ciphertext into another note's row, decryption would fail instead of quietly showing you the wrong note.

What the server sees, and what it never receives

End-to-end encryption does not mean the server knows nothing. It means the server can't read what you wrote. Here is the full picture for Cappa, based on our security documentation and database schema.

The left column is called metadata: data about your data. It is not your notes, but it is not nothing. Someone with the database could learn that an account exists, roughly how many notes it has, how large they are and at what hours the owner writes. That is why we describe Cappa's encryption as protecting the content of your notes, not your activity.

The email provider that delivers Cappa's messages sees your address too. Besides your invitation, Cappa emails you when something security-related happens to your account, such as a changed master password, a replaced recovery code or a new browser added. Those emails contain no secrets or links, but the provider learns what kind of event happened and when. Big vendors face the same metadata trade-off: Apple documents that even with its opt-in Advanced Data Protection, some Notes metadata, such as when a note was created or last modified, stays under standard protection.

How one password becomes two keys

Here is Cappa's key hierarchy, the chain from what you type to what encrypts your notes. It all happens in your browser.

Master password

Typed on your device. Never sent anywhere.

Argon2id

Root key

Exists briefly in memory, then is wiped.

split in two

Two keys

• Login key: sent to the server to prove it's you.
• Password key: stays in the browser and opens the envelope.

Step by step:

1. You type your master password. It never leaves the browser. The master password guide covers how long it should be.
2. Argon2id stretches it into a root key. Argon2id is a deliberately slow, memory-hungry function (standardized in RFC 9106). In Cappa each run needs 64 MiB of memory and three passes, which is quick for you once but expensive for someone trying billions of guesses. The salt, a value that makes your result unique, is built from your email address and a random seed. See Argon2 explained simply for how this works.
3. The root key is split into two independent keys. Knowing one doesn't reveal the other.
4. The login key goes to the server. The server treats it like an ordinary account password and hashes it again with Argon2id before storing it. The server never sees the password it came from.
5. The password key stays with you. It opens the "password envelope," an encrypted package stored on the server that contains your vault key.
6. The vault key encrypts every note. Your vault is the encrypted collection of all your notes, and its key is a random 256-bit key created in your browser when your account was set up. Each note is encrypted with it using AES-256-GCM and a fresh nonce.

Vault header, stored on the serverreadable only as ciphertext

Password envelopeopens with the password key

Vault keyrandom, 256 bits

Recovery envelopeopens with your recovery code

The same vault keyrandom, 256 bits

Why the extra layer? Why not encrypt notes with the password key directly? Because then changing your password would mean re-encrypting every note. With an envelope, a password change just seals the same vault key in a new envelope. It also allows a second envelope for your recovery code, a long random code you save when you create your account. In Cappa, recovery also needs an administrator to open a 60-minute recovery window for your account, so a stolen code alone is not enough.

What does zero-knowledge encryption mean?

"Zero-knowledge" is a popular label for this design. In marketing it usually means: the provider has zero knowledge of your content, because it never holds the key. (Cryptographers also use "zero-knowledge proof" for something different, a way to prove you know a secret without revealing it.)

We avoid claiming "zero-knowledge" in an absolute sense, for two reasons.

First, metadata. As the list above shows, the server knows quite a lot about your account. "Zero" isn't accurate.

Second, the app itself comes from the server. Cappa is a web app. Each time you open it, your browser downloads its code from Cappa's server. Encryption in your browser protects you if someone steals the database or backups, or if an administrator looks at them. It cannot protect you if the server itself is compromised and sends you modified code, because that code runs where your password and notes are unlocked. It could capture them the next time you use the app. This is true of every browser-based end-to-end encrypted app, not just ours. Installed apps from an app store shift this risk to the store's update process but don't remove it.

So the accurate claim is narrower and still useful: someone with Cappa's database or backups can't read your notes without guessing your master password, and each guess costs a full Argon2id run. What encryption can't protect you from covers the other gaps, such as malware on your device, a browser extension or someone at your unlocked computer.

What end-to-end encryption costs you

If the company can't read your notes, it can't do anything that requires reading them. Know the trade-off before you choose.

• No password reset. Cappa's administrator can't reset your password, because a new password wouldn't open the old envelope. If you lose both your master password and your recovery code, your notes can't be decrypted by anyone.
• Search, previews and links happen on your device. The server can't search text it can't read. In Cappa, search runs in your browser over your unlocked notes.
• No server-side features that read content. Server-side AI summaries, web clipping processed in the cloud or email-to-note would all need plaintext on a server.
• Sharing is harder. Letting someone else read a note means giving them a key. Cappa is a single-person notebook and has no sharing or collaboration.

Some of these costs are softened by keeping a full copy on each device. That is the idea behind local-first software: your notes live on your device first, work offline, and sync as encrypted records. In Cappa, the local copy in your browser is also stored encrypted, and plain text exists only while the app is open and unlocked.

How to tell if a notes app is end-to-end encrypted

You don't need to read source code. Four questions get you most of the way:

1. Who holds the key? Look for wording like "encrypted on your device" and "we can't access your notes." "Encrypted in transit and at rest" alone means the company holds the key.
2. Is it the default? Some apps offer end-to-end encryption only for a locked note, a password-protected section or an opt-in setting.
3. Can the company recover your notes if you forget your password? If yes, it has a way to decrypt them.
4. What metadata is visible? An honest provider lists it.

We applied these questions to popular apps, from Notion and Google Keep to Apple Notes and Obsidian, using each vendor's own documentation, in Can your notes app read your notes?

FAQ

Is end-to-end encryption the same as zero-knowledge encryption?

They usually describe the same design: the provider never holds the key to your content. "Zero-knowledge" can overstate it, because the provider still sees metadata such as your email, sizes and timestamps, and a web app's code comes from the provider's server. We prefer the precise claim: the server stores your notes only as ciphertext it can't decrypt.

Does HTTPS mean my notes are end-to-end encrypted?

No. HTTPS protects the connection between your browser and the service, and it is decrypted at the service's servers (or its proxy). What happens after that depends on who holds the key. End-to-end encryption means the data inside the HTTPS connection is already encrypted with a key the service doesn't have.

Can Cappa reset my master password if I forget it?

No. Nobody at Cappa knows your vault key, so a password set by an administrator couldn't open your envelope. You can regain access with your recovery code, which also requires an administrator to open a recovery window for your account. Without either the password or the code, the notes can't be decrypted.

Can end-to-end encrypted notes still be hacked?

Yes, but not by reading the server's database. The weak points move to your devices and your password: malware, a malicious browser extension, a phishing page, a weak master password that can be guessed offline, or modified app code from a compromised server. End-to-end encryption narrows who can read your notes; it doesn't make anything unbreakable.

How can search work if the server can't read my notes?

Search runs on your device after you unlock your notes. Cappa keeps an encrypted copy of your notes in your browser, decrypts it when you unlock the app, and searches it locally. The server never takes part.