The File Format Decision Most Writers Never Think About

Written by

AnySlate Team

7 min read

I didn't think much about this at first either.

When I started building AnySlate, I spent months obsessing over the editor experience — block editing, slash commands, real-time collaboration. The stuff people actually talk about. File format felt like a plumbing decision. Boring. Low-stakes. Obvious.

It isn't.

There are two categories of writing tools, and they look nearly identical from the outside. Choosing between them is probably the most consequential call you'll make about your content library. Most people make it without realising they're making it at all.

The hidden choice hiding in plain sight

Markdown-compatible tools — think Notion, Bear, Craft — let you write using Markdown syntax and export to .md files when you ask nicely. But the actual storage underneath is proprietary: a database, a custom schema, or a binary system managed entirely by the company. Markdown is the exit door, not the house.

Markdown-first tools store your content in real .md files from the moment you hit save. No conversion involved. No hidden schema humming in the background. Tools like Obsidian and AnySlate work this way. Your words are readable and portable from day one - not just when you decide to leave.

A simple rule: If your notes only become Markdown when you click "Export," you are not using a Markdown-first tool. You are using a tool that tolerates Markdown.

Markdown-compatible vs. Markdown-first

Markdown-compatible

Markdown-first

Where content actually lives

Proprietary database or schema

Real .md files on disk

Export needed to leave?

Yes — always

Never

Link & structure fidelity

Often breaks on export

Always intact — it's native

Portability

As good as the export feature

Unconditional, always

AI & MCP friendliness

Copy-paste required

Native read/write

What "compatible" actually means in practice

When a tool is Markdown-compatible, you're extending a lot of quiet trust. You trust the export feature will always work correctly. You trust the company will stay solvent. You trust that the proprietary format won't introduce enough complexity to corrupt your data at the exact moment you need it most.

That's a lot of trust to extend to a business you have zero control over.

The practical experience rarely matches the marketing. Internal links break. Nested structures flatten. Custom block types get stripped. The files you get back are technically Markdown, but they're not really your notes - they're a ghost of them.

And the incentive problem is real. A tool with a proprietary format has an actual business reason to keep it proprietary. Every feature built into a custom schema makes switching harder. Every year you write in it, the lock-in deepens. That's not an accident. It's the architecture of the thing.

Real scenario — Imagine keeping your product docs, research notes, and drafts in one system for five years. Everything is organised. Links between notes work. It's a proper knowledge base, not just a folder of text.

Then a migration happens. What survives is the text. What gets weird is everything that made the notes useful: links, structure, embeds, hierarchy. You end up with technically portable files that are practically damaged.

That is the difference between a format you own and a format you are borrowing.

File format is infrastructure

We spend time thinking about features. The editor experience. Collaboration tools. AI integration. We almost never think about file format as a foundational decision.

But it is. Your file format is the load-bearing wall of your content library. Everything else is furniture.

I've seen people obsess over fonts, slash commands, and AI assistants, then hand over ten years of notes to a format they can't actually inspect.

If your content lives in real Markdown files - not as an export, but as the actual storage - no company can hold your library hostage. The app shuts down tonight; you open your files in another editor tomorrow. No conversion. No rescue operation.

"A file format is like plumbing. Nobody posts about it until the walls start leaking."

The trade-off that isn't really a trade-off

The usual objection is: "But Markdown-first tools aren't as powerful."

In 2026, this is no longer true. And I'm not just saying that because I build one, it's a category mistake that keeps getting repeated.

A Markdown-first editor can support real-time collaboration, cloud sync, version history, block editing, Mermaid diagrams, LaTeX math, and syntax highlighting for 190+ languages — while your files remain plain .md on disk. Proprietary formats exist to make feature development easier for the company building the tool. Not because Markdown can't handle the features.

Export is a fire escape, not a front door. You shouldn't have to use it to go about your day.

AnySlate - Markdown-first, not feature-poor. Everything you'd expect from a modern writing tool. None of the format lock-in.

  • Real-time collaboration

  • Cloud sync

  • Block editing

  • Publishing & sharing

  • Mermaid diagrams

  • LaTeX math support

  • Syntax highlighting for 190+ languages

  • MCP / AI native

All of it. Files stay plain .md on disk the whole time.

What native MCP changes

In 2026, a lot of people are building AI-native workflows - using tools like Claude, Cursor, or Windsurf to research, draft, and organise their writing. Where your files actually live matters more than it ever did.

If your content is locked in a proprietary format, your AI agent can't read it natively. You're stuck copy-pasting and reimporting. The friction compounds every single session.

If your content is real Markdown, an AI agent with MCP access can read documents, search your library, create files, and edit specific sections - without ever leaving your editor. The files become the interface.

With a proprietary format, step one in that diagram is already blocked. You're not building a workflow - you're managing a workaround.

The honest caveat

Markdown-first isn't right for everyone. If you need database views, relational properties, and project management deeply embedded in your notes, Notion's proprietary format does things that a plain .md file genuinely cannot. That trade-off is real, and for some workflows, it's the right call.

The point isn't that Markdown-first is universally superior. It's that the choice shouldn't be made by default - by picking a tool without ever asking the question. Most people who end up locked into a proprietary format never decided to be there. They just didn't think about it.

"A proprietary note format is very convenient right up until it becomes a hostage situation. Your notes should not require a rescue mission."

Why I built AnySlate this way

I build AnySlate, so yes - I have a point of view here. But I also think this is a category mistake people keep repeating, and it costs them eventually.

The moment this clicked for me was when I realised export is not ownership. They feel the same until the day they aren't. I wanted to build a writing experience that felt genuinely modern - collaboration, cloud sync, block editing, AI workflows - without asking writers to give up ownership of the underlying file.

That belief shaped every architectural decision in AnySlate. Your content stays readable, portable, and AI-native. Not because you remembered to export it. Because that's just how it works.

One decision, made once

Choose a Markdown-first tool at the start. Every word you write is portable, permanently readable, and AI-native from that point on.

You don't have to think about it again.

You just write.

Markdown-First vs Compatible: Who Owns Your Notes? | AnySlate Blog