How to Encrypt Your Notes: A Practical Privacy Guide

Your notes are the most honest thing you own. They hold half-formed ideas, client details, passwords you jotted down at 2am, the draft of a resignation letter, the name of the doctor you meant to call. Most people write all of that into apps that store it in plain text on someone else's server. This guide walks through how to actually encrypt your notes, what each method protects against, and where the common tools quietly leave gaps.

Quick Answer: To encrypt your notes properly, you need three things: strong encryption (AES-256 is the standard), a key that only you control (derived from your password, never stored by a company), and a recovery plan for when you forget that password. Notion does not encrypt your notes at rest for you, and Obsidian has no native encryption (you rely on a plugin). Tools like Filarr, Standard Notes, or Cryptee encrypt on your device before anything touches disk or cloud, so nobody but you can read the content. The practical move is to pick a tool that encrypts locally by default, use a long unique passphrase, and save your recovery phrase somewhere offline.

Why this matters more than people think

Encryption sounds like an IT department problem. It is not. It is about who can read your day. When your notes live unencrypted on a cloud service, several people can potentially see them: employees of the company (support staff, engineers debugging an issue), anyone who breaches the company's servers, law enforcement with a subpoena the company must honor, and any partner the service shares data with. You are trusting all of them by default, silently, forever.

The goal of encrypting your notes is simple: make the content unreadable to everyone except you. Done right, even if someone steals the hard drive, breaches the cloud bucket, or compels the company to hand over your files, all they get is noise. That is the difference between "my data is stored securely" (a promise) and "my data is mathematically unreadable without my key" (a property).

This guide is for anyone who keeps a second brain in a notes app: developers with API keys in their scratchpad, freelancers with client contracts, journalists, people managing health or legal matters, or anyone who just does not love the idea of their private thoughts sitting readable on a server in another country.

Understand what you are actually protecting against

Before choosing a method, name your threat. Encryption is not one thing, and the right setup depends on what you are worried about.

Someone steals your laptop or phone. This is the most common real-world threat. Here, full-disk encryption (FileVault on macOS, BitLocker on Windows, LUKS on Linux) already helps a lot, because a powered-off device with disk encryption is hard to read. But full-disk encryption stops protecting you the moment the device is unlocked and running. If your notes app has no lock of its own, anyone with your unlocked laptop reads everything.

The cloud service gets breached or reads your data. Full-disk encryption does nothing here, because your notes left your disk in readable form and got stored on their server. This is where end-to-end or client-side encryption matters: the content is encrypted before it leaves your machine, so the server only ever holds scrambled blobs.

A company is compelled to hand over your data. Same answer. If the provider never had your key, they can only hand over ciphertext. This is the actual meaning of "zero-knowledge": the service literally cannot read what it stores.

Once you know which of these you care about, the tool choice gets easier. Most people want protection against all three, which points toward client-side encryption with a key you control.

Method 1: Full-disk encryption (the baseline everyone should have)

Start here regardless of which notes app you use. Full-disk encryption protects everything on the machine when it is off or locked.

On macOS, open System Settings, go to Privacy and Security, and turn on FileVault. Save the recovery key somewhere that is not on the same machine. On Windows Pro editions, search for "Manage BitLocker" and enable it on your system drive; Home editions have a lighter "Device Encryption" under Settings if your hardware supports it. On Linux, LUKS is usually offered during install as "encrypt the disk," and enabling it at install time is far less painful than adding it later.

The honest limitation: this protects the disk, not the app. It is necessary but not sufficient. Once you type your login password and the machine is running, your notes are decrypted and readable to any process or person with access to that session. Treat full-disk encryption as the floor, not the ceiling.

Method 2: Per-note or per-vault encryption inside a general notes app

If you already live in a tool like Obsidian or Notion, you can bolt on encryption, but you need to understand exactly what you are getting.

Obsidian stores your notes as plain Markdown files on disk. There is no native encryption. Your options are: put the whole vault inside an encrypted container (a VeraCrypt volume, or a Cryptomator vault synced to your cloud), or use a community plugin such as one that encrypts individual notes. The container approach is solid and battle-tested, but clunky day to day: you mount the volume, work, unmount it. The plugin approach is convenient but fragile, because it depends on one developer maintaining a piece of code that sits between you and your data. If the plugin breaks after an Obsidian update, you can be locked out of your own notes until it is fixed. That is a real risk worth weighing.

Notion does not offer end-to-end encryption. Your pages are encrypted in transit and encrypted at rest on Notion's infrastructure with keys Notion controls, which means Notion can read your content. There is no user-facing option to change that. If your threat model includes "the company or anyone who reaches its servers should not read this," Notion is the wrong tool for those particular notes, and no setting fixes it. Use it for things you would not mind being readable, and keep the sensitive material elsewhere.

The takeaway for Method 2: adding encryption to a tool that was not built for it works, but it is always a workaround, and workarounds have edges you will eventually hit.

Method 3: A notes app that encrypts locally by default

The cleanest option is a tool where encryption is not a feature you enable but the way the app works. Here the content is encrypted on your device with a key derived from your password before anything is written to disk or sent to a server. Standard Notes, Cryptee, Proton's tools, and Filarr all sit in this category, with different trade-offs.

I work on Filarr, so I will use it as the worked example, and I will be straight about where other tools do things it does not.

With a local-first encrypted app, the flow looks like this. You set a vault password when you first open the app. That password is run through a slow key-derivation function to produce your master key. In Filarr the derivation is PBKDF2 with SHA-512 at 600,000 iterations, which follows the OWASP 2024 recommendation, with Argon2id (64 MB memory, 3 iterations, 4 threads) available as a stronger option. "Slow" is the point: it makes brute-forcing your password by trying billions of guesses computationally expensive.

Each file gets its own encryption key, and that per-file key is itself encrypted (wrapped) by the key derived from your password. The actual content is encrypted with AES-256-GCM, a standard authenticated cipher, and every file is stored as its own encrypted blob on your disk. Because the app is local-first, all of this happens whether or not you ever turn on cloud sync. Offline, your notes are already encrypted at rest on your own machine.

What this buys you in practice: if someone copies the files off your disk, they get opaque encrypted blobs and no key. The key exists only when you unlock the app with your password. The company running the service (in Filarr's case, the optional cloud sync) never receives your password or key, only the already-encrypted blobs.

Method 4: Handle sync without giving up encryption

The hard part of encrypted notes has always been sync. You want your notes on your laptop, your phone, and backed up somewhere, but sync usually means handing readable data to a server. Client-side encryption solves this by syncing only the ciphertext.

In a properly designed encrypted app, sync uploads the same encrypted blobs that already sit on your disk. Nothing is decrypted for the server. In Filarr, cloud sync is optional and stores encrypted opaque blobs on Cloudflare R2; the server holds ciphertext it cannot read, and if you would rather not use the hosted backend at all, you can bring your own S3-compatible bucket. The mental model to insist on with any tool: the server should be a dumb box that stores scrambled data, not a service that processes your content.

When you evaluate a tool's sync, ask one question: does the server ever hold my notes in a form it can read? If the answer is yes (Notion, Google Keep, most mainstream apps), sync convenience is costing you privacy. If the answer is no, you get both.

The step everyone skips: recovery

Strong encryption has a sharp edge. If only you hold the key and you lose it, your notes are gone. Truly gone. There is no "forgot password" email that recovers end-to-end encrypted data, because a recoverable-by-the-company system is by definition one where the company holds a key.

This is why recovery planning is not optional, it is the other half of encrypting your notes. Good tools give you a recovery phrase: a list of words (Filarr uses a 24-word BIP-39 phrase, the same standard used by crypto wallets) that can regenerate your access. Write it on paper. Store it somewhere physically safe and separate from your device, for example a home safe or a sealed envelope with important documents. Do not store your recovery phrase in the same notes app it unlocks, and do not email it to yourself.

A second layer of safety is your own encrypted backups. Export or copy your encrypted vault to an external drive periodically. Because the files are already encrypted, the backup is safe to keep on a drive that is not itself encrypted, though belt-and-suspenders never hurt. The point is redundancy: encryption protects you from other people, backups protect you from yourself.

Pitfalls and good practices

A weak password undoes everything. AES-256 is unbreakable in practice, but it protects a door whose key is your password. If your password is "summer2024," no amount of cryptography saves you. Use a long passphrase, four or five random words is stronger and more memorable than a short cryptic string, and never reuse it from another account.

Beware apps that offer "password reset" for encrypted data. If a service can reset your password and still show you your old notes, it means the service holds your key. That is not end-to-end encryption, whatever the marketing says. Real client-side encryption forces a recovery phrase precisely because it cannot reset your way back in.

Do not confuse "encrypted in transit" with "encrypted for you." Almost every app uses HTTPS, which encrypts data while it travels. That is table stakes and says nothing about whether the company can read your notes once they arrive. Look specifically for "end-to-end," "client-side," or "zero-knowledge" encryption.

Screenshots, clipboards, and exports leak. Encryption protects storage, not what you do with decrypted content. A note you paste into an unencrypted chat, or export to a plain PDF on your desktop, is no longer protected. Be deliberate about where decrypted copies land.

Match the tool to the maturity you need. Be honest with yourself about trade-offs. Obsidian has a huge plugin ecosystem and a large community; a younger encrypted app like Filarr has fewer plugins and a smaller community (it is a 2026 project, with mobile still in progress). If deep extensibility matters more than native encryption for a given use, that is a legitimate choice. Encrypt the notes that need it, and do not force one tool to be everything.

A concrete setup you can copy

Here is a setup that covers all three threats without much friction. Turn on full-disk encryption on every device (baseline against theft). Keep your genuinely sensitive material in a local-first encrypted app with a strong unique passphrase, so the content is unreadable at rest and in the cloud. Turn on encrypted sync if you need multiple devices, confirming the server only ever holds ciphertext. Write your recovery phrase on paper and store it offline, separate from your devices. Keep a periodic encrypted backup on an external drive.

That combination means a stolen laptop gives up nothing, a breached cloud gives up nothing, and a forgotten password does not cost you your notes. It takes about twenty minutes to set up and then mostly runs itself.

FAQ

Is full-disk encryption enough to protect my notes? No. Full-disk encryption protects your notes when the device is off or locked, but once you log in and the machine is running, your notes are decrypted and readable to anyone with access to that session or to the cloud service holding a plain copy. It is a necessary baseline, not a complete solution. Pair it with a notes app that encrypts content on your device.

Does Notion encrypt my notes? Notion encrypts data in transit and at rest on its servers using keys Notion controls, which means Notion itself can read your content and so can anyone who breaches or subpoenas it. Notion does not offer end-to-end encryption, and there is no setting to enable it. For notes you need kept private from the provider, use a client-side encrypted tool instead.

What is the difference between encrypted in transit and end-to-end encryption? Encrypted in transit (HTTPS) protects data only while it travels between your device and the server; the server can still read it on arrival. End-to-end or client-side encryption encrypts the content on your device before it is sent, so the server only ever stores scrambled data it cannot read. For private notes, you want the second kind.

What happens if I forget my password? With real end-to-end encryption, the company cannot recover your notes, because it never held your key. That is why these tools give you a recovery phrase (Filarr uses a 24-word BIP-39 phrase) when you set up your vault. Write it down and store it offline. If you lose both your password and your recovery phrase, the encrypted notes cannot be recovered by anyone.

Is AES-256 encryption actually secure? AES-256 is a widely trusted standard used by governments and banks, and there is no known practical attack against it. The weak point is almost never the cipher; it is the password protecting the key. A short or reused password can be brute-forced regardless of the cipher, so use a long unique passphrase and let the app's key-derivation function (such as PBKDF2 with 600,000 iterations, or Argon2id) do its job.

Can I keep syncing my notes across devices if they are encrypted? Yes, if the tool is built for it. Client-side encrypted apps sync the already-encrypted blobs, so the server stores ciphertext it cannot read while your devices stay in sync. Filarr, for example, offers optional sync that uploads encrypted blobs to Cloudflare R2, or to your own S3-compatible bucket. Confirm that the server never holds a readable copy.

Conclusion

Encrypting your notes is not one switch, it is a small stack: full-disk encryption as the floor, a client-side encrypted app for the notes that matter, encrypted sync if you need it, and a recovery phrase stored offline so a lost password does not become a lost decade of thinking. The mechanics are handled by the tools; your job is to pick one that encrypts locally by default, choose a strong passphrase, and back up the recovery phrase before you need it. Do that once, and the most honest record of your life stops being readable to anyone but you.

If you want a tool where this is the default rather than a workaround, Filarr encrypts every file locally with AES-256-GCM before it touches disk, keeps sync optional, and is free forever for local use. But the principle outlives any single app: own your keys, plan your recovery, and stop trusting servers to keep secrets they can read.