The Obsidian Encryption Problem —
And How to Solve It

Obsidian is one of the best note-taking applications ever built. The markdown-first approach, the graph view, the plugin ecosystem, the community — it has earned its reputation. But if you store sensitive information in Obsidian, you have a problem. There is no built-in encryption. Your API keys, passwords, and private notes sit as plain text files in a folder that any application on your computer can read. Here is what the community has tried to do about it, why each approach falls short, and what a purpose-built solution looks like.

Why Obsidian Users Want Encryption

Obsidian attracts a specific kind of user: someone who thinks in documents, who wants their knowledge connected, and who cares about owning their data. These same users tend to be developers, system administrators, security engineers, and technical professionals who work with sensitive information every day.

The problem surfaces gradually. You start using Obsidian for project notes. Then you add a database connection string to your deployment notes because it is convenient. Then you paste an API key into your AWS documentation because you are tired of switching to 1Password. Then you realize your entire vault — synced to iCloud, backed up to Dropbox, indexed by Spotlight — contains credentials in plain text files that any app, any backup service, and any person with access to your laptop can read.

The Reddit threads and Discord discussions about this are endless. "How do I encrypt notes in Obsidian?" is one of the most common questions in the community. The answers are always the same three options, and none of them are great.

The Current Options

Option 1: Obsidian Encrypt Plugin

The most popular community approach is the Obsidian Encrypt plugin, which lets you select text within a note and encrypt it in place. You highlight a block, press a hotkey, enter a password, and the selected text is replaced with an encrypted blob. To read it, you click the blob and enter the password again.

This sounds perfect in theory. In practice, the limitations add up quickly. Each encrypted block requires its own password entry — there is no master key that unlocks everything. If you have twenty encrypted blocks across ten notes, you are entering passwords twenty times per session. The encrypted blobs break markdown rendering — they appear as opaque inline elements that confuse other tools and export workflows. Search does not work on encrypted content. Git diffs are meaningless because the entire encrypted blob changes even if you edit one character. And the plugin is maintained by a single community developer with no formal security audit.

Option 2: Cryptomator

Cryptomator creates an encrypted virtual filesystem. You create a vault, set a password, and mount it as a drive. Your Obsidian vault lives inside this encrypted drive. When the drive is mounted, Obsidian reads and writes files normally. When you unmount it, everything is encrypted on disk.

This approach provides genuine, audited encryption for your entire vault. But it introduces serious workflow problems. Cloud sync becomes unreliable — Cryptomator encrypts filenames and file contents, and sync services like iCloud and Dropbox often create conflicts because they cannot merge encrypted files intelligently. More critically, Git does not work inside a Cryptomator vault. The encrypted filenames change on every save, so Git sees every file as completely rewritten. Your commit history becomes useless. Branching and merging are impossible. If you use Git for version control (as many Obsidian users do), Cryptomator breaks your workflow.

Option 3: External Secret Storage

The third approach is to keep secrets out of Obsidian entirely. Store credentials in 1Password, Bitwarden, or KeePass. Reference them in your Obsidian notes with a comment like "see 1Password entry: AWS Production." Never put the actual secret in your vault.

This works from a security perspective. It also defeats the purpose of having a connected knowledge base. Your documentation is in one app and your credentials are in another. Every time you deploy, debug, or reference infrastructure, you switch between tools. The context and the credential are permanently separated. You cannot build a complete deploy runbook because half the information lives somewhere else.

The Fundamental Design Tension

The core issue is not that Obsidian is missing a feature. It is that Obsidian's architecture makes per-secret encryption genuinely difficult to implement well. Obsidian is built around the idea that your vault is a folder of plain markdown files. Every plugin, every theme, every integration assumes it can read and manipulate those files as plain text. The graph view parses markdown links. The search indexes full-text content. The preview renders markdown to HTML.

If you encrypt an entire file, search stops working. Graph view cannot parse links inside encrypted content. Preview cannot render encrypted markdown. Backlinks break. Tags inside encrypted notes are invisible. The entire knowledge graph — the feature that makes Obsidian unique — loses a chunk of its data.

If you encrypt parts of a file (like the Obsidian Encrypt plugin does), you break the assumption that every file is valid markdown. Other plugins that parse file content may crash or produce incorrect results. Export workflows that process markdown will include the encrypted blobs as literal text. The editing experience degrades because you are constantly encrypting and decrypting inline blocks.

Obsidian was not designed to be a secure vault. It was designed to be a knowledge management tool. These are different problems that require different architectures. Trying to bolt encryption onto Obsidian is like trying to add a safe to a filing cabinet — you can do it, but the cabinet was not built for it, and the result is always a compromise.

A Different Approach: Per-Block Encryption

Claspt was built from the ground up to handle the exact problem Obsidian users face: storing notes and secrets in the same document. The key architectural difference is that encryption is a first-class concept in the editor, not a plugin added after the fact.

When you create a secret block in Claspt, the editor understands that this block contains encrypted content. It knows how to render it (showing a locked icon and the field label), how to search it (the label is searchable, the value is not), how to diff it (showing that a secret changed without revealing old or new values), and how to export it (preserving the enc:v1: format that any decryption tool can process).

The rest of your document — your headings, paragraphs, code blocks, checklists, and links — remains plain markdown. It is searchable, diffable, and renderable by any tool. The file is valid markdown whether or not you have Claspt installed. The encrypted blocks appear as enc:v1:<base64> strings, which are ugly but harmless in any markdown renderer.

Because encryption is integrated into the editor rather than bolted on, there is no password entry per block. You unlock your vault once with your master passphrase, and all secret blocks in all files are decryptable for that session. One password, all secrets, zero friction.

What You Keep vs. What Changes

Moving from Obsidian to Claspt is not a wholesale replacement. Obsidian excels at things Claspt does not attempt:

• Graph view and backlinks. Obsidian's knowledge graph is unmatched. Claspt has no graph view. If your workflow depends on visualizing connections between notes, Obsidian is the better tool for that specific function.
• Plugin ecosystem. Obsidian has 1,800+ community plugins. Claspt has zero. If you rely on specific plugins (Dataview, Templater, Calendar), those do not exist in Claspt.
• Community and themes. Obsidian has a massive community, hundreds of themes, and a rich ecosystem of shared workflows. Claspt is a new, focused tool with a small user base.

What Claspt offers that Obsidian cannot:

• Built-in encryption. Per-block AES-256-GCM encryption with Argon2id key derivation. Not a plugin. Not a workaround. A core feature.
• Git that works. Because files are plain markdown with inline encrypted blocks (not Cryptomator-encrypted binaries), Git diffs, commits, branches, and merges all work correctly.
• One-unlock access. Enter your passphrase once per session. All secrets in all files are accessible. No per-block password entry.
• Security-first architecture. Rust backend with zeroize for memory safety. Decrypted values are wiped from RAM immediately after use. Not an Electron app with JavaScript garbage collection.

An Honest Comparison

If you do not store sensitive information in your notes, stay with Obsidian. It is the better tool for pure knowledge management, and adding Claspt would add complexity without solving a problem you actually have.

If you store a few passwords or API keys in Obsidian and the Encrypt plugin is sufficient for your needs, that is a reasonable choice. The plugin is not perfect, but it is convenient and stays within a single app.

If you store significant amounts of sensitive information — deploy credentials, infrastructure access, client secrets, personal documents — and you need search, Git integration, and real encryption, that is the problem Claspt was built to solve. You can import your Obsidian vault and keep your non-sensitive notes in Obsidian while using Claspt for the pages that contain secrets.

Many users run both. Obsidian for the knowledge graph, reading notes, and general writing. Claspt for infrastructure documentation, deploy runbooks, and anything that contains credentials. The tools are not mutually exclusive. They solve different problems.

For a detailed feature-by-feature breakdown, see our Claspt vs Obsidian comparison page.