Markdown editors: what separates a reader from a writer

Markdown is simple enough that any text editor can write it, which is why choosing a markdown editor is confusing: everything from a plain notes app to a full publishing environment claims to support it. The apps differ enormously, and the difference is not features — it is whether the app is built for reading someone else's files or writing your own.

A markdown editor is an application for writing and editing .md files, as distinct from a reader, which is built to display them well. Most people want one of those two things clearly, and the frustration of a bad fit comes from installing the other.

Reader or writer

A markdown editor and a markdown reader optimise for opposite things.

A reader opens files quickly, renders them faithfully, handles large documents, and navigates a folder of them. It is the right tool for documentation you did not write, a repository's notes, a manual, an exported archive. Apps built for this — such as Mdora — are judged on rendering fidelity and how fast they open something, not on typing comfort.

A writer optimises the act of typing: shortcuts, live preview, a comfortable editing surface, and no friction between thought and text. It usually renders adequately rather than beautifully.

Ask whether you spend more time typing or more time reading. The answer picks your category before any feature list does.

What actually separates writers

Six things separate one markdown editor from another, and the ordering surprises people.

• Where the files live. Plain .md files in a folder you control, versus a proprietary database. This is the single most consequential difference, because it determines whether you can leave.
• Preview behaviour. Side-by-side, inline rendering as you type, or a toggle. Inline suits prose; side-by-side suits documents with structure; a toggle suits people who find preview distracting.
• Keyboard support. Shortcuts for headings, links, lists and formatting. On a laptop this is most of the daily experience.
• How links between notes work. Whether typing a reference to another file creates a working link, and whether the app can show you what links back.
• Handling of images. Pasting a screenshot should put a file somewhere sensible and insert a relative path, not embed a blob.
• Sync. Files in a synced folder work everywhere; an app's own sync usually works better and only within the app.

The first point deserves emphasis. Markdown's advantage over every other note format is that the file is readable by anything, forever, with no application at all. An app that stores markdown-flavoured text inside its own database has taken that away while keeping the syntax, which is the worst of both.

The rendering differences that cause trouble

Markdown is not one specification, and the variations show up exactly where documents matter.

Tables. Not in the original spec, supported by most tools now, rendered differently by some.

Code fences and syntax highlighting. Nearly universal, with variation in which languages are recognised.

Task lists. Widely supported, occasionally rendered as plain text.

Footnotes, definition lists, math. Support varies considerably, and math in particular is an extension rather than a feature.

Front matter. The block of metadata at the top of a file. Some apps use it, some display it as text at the start of the document, which looks broken.

The practical rule: if your files are going somewhere specific — a static site, a repository, a publishing pipeline — test them there rather than in the editor. The editor's rendering is a preview of its own opinion, and the destination's opinion is the one that matters.

Choosing on a phone versus a laptop

The same person often needs a different markdown editor on each, and forcing one to serve both produces a poor fit.

On a phone, capture speed matters most: how quickly the app opens to a blank note, whether it handles the share sheet, whether voice dictation works well. Long-form writing on a phone is rare, and optimising for it is optimising for the wrong session.

On a laptop, the editing surface and keyboard support dominate, and preview becomes genuinely useful because there is room for it.

The arrangement that works for most people is a plain folder synced between devices, with whichever app fits each device reading and writing the same files. That is only possible if both apps use real files — which brings the point above back around, and is the practical reason it matters.

What about the apps that are really databases?

A large part of the markdown editor category is note applications that support the syntax without using markdown files, and they deserve a fair hearing rather than dismissal.

What they buy you is real: fast search across thousands of notes, links that update when a file is renamed, backlinks computed instantly, and sync that works reliably because the app controls both ends. These are genuine advantages, and for someone with 5,000 notes they matter daily.

What they cost is also real, and it is one thing: the exit. Three questions settle whether the trade is acceptable:

1. Does it export to plain files, with structure intact? Not a JSON dump — a folder of .md files with working relative links.
2. Can you run that export today, in under 5 minutes, without support? An export feature that exists in documentation but takes a week is not an exit.
3. Do the exported links still work? This is where most exports fail, because internal references were never file paths.

Run the export before you commit rather than when you want to leave. It takes 10 minutes, and the answer determines whether the app is a tool or a container.

A reasonable middle position that many people land on: a database app for the working set where its speed and linking earn their keep, and plain files for anything that must outlive the app — drafts, documentation, reference material. Two systems is not elegant, and it is honest about what each is good at.

When markdown is the wrong choice

Being honest about the limits saves a migration later.

Collaborative editing. Markdown files do not merge gracefully when two people edit the same paragraph. For genuinely simultaneous writing, a collaborative editor is the right tool.

Complex layout. Multi-column, precise typography, anything designed rather than structured. Markdown expresses structure, not layout.

Heavy tables and data. A table beyond a few columns is painful to write and read as text. That is a spreadsheet.

Documents needing tracked changes and comments. Possible with version control, and unfamiliar to anyone expecting a word processor.

Where markdown wins is durability and portability: a folder of .md files is readable in thirty years, searchable by any tool, versionable with git, and free of any company's continued existence. That is a genuinely rare property, and it is worth the trade for personal notes, documentation and drafts.

A setup that survives changing your mind

Four decisions that keep the option open.

1. Keep files in one folder, organised by subfolders rather than by app-specific structures.
2. Use relative links between files and to images, so moving the folder does not break them.
3. Keep images beside the text, in a subfolder, rather than in an app's storage.
4. Test the folder in a second app occasionally. If it opens correctly elsewhere, you are not locked in — and if it does not, you have found that out cheaply.

More productivity picks in productivity software, comparisons in comparisons, and general tools in software. The CommonMark specification is the closest thing to a standard if you want to know what should render everywhere.

The short version

Decide whether you are reading or writing before comparing features. A markdown editor optimises typing; a reader optimises opening, rendering and navigating files someone else wrote.

Then choose one that keeps your work as plain .md files in a folder you control, with relative links and images stored beside the text — because that is the property that lets you change your mind later, and it is the reason to use markdown at all rather than any particular app's feature list.