Your Markdown Editor Is Quietly Rewriting Your Files

Open a markdown file in a live-preview editor. Fix a typo in paragraph nine. Save. Diff the file against the original.

There is a decent chance that lines you never touched have changed.

Why this happens

There are two ways to build an editor that renders markdown as you type.

Parse it into a rich text model. The editor converts markdown into an internal document tree, renders that tree, and serialises it back to markdown on save. This is easier to build and gives you the nicest editing behaviour.

Keep the raw text and decorate it. The buffer stays markdown. The editor draws headings large and bold without ever converting them into a "heading object". CodeMirror and similar libraries work this way.

The first approach has a structural problem: serialising back out is a lossy, opinionated act.

What actually changes

The model has to make choices your file already made:

• - item and * item are the same list. The serialiser picks one.
• _emphasis_ and *emphasis* are the same emphasis. It picks one.
• Setext headings become ATX headings, or the reverse.
• Trailing spaces, blank line counts and indentation get normalised.
• Tables get realigned.

None of that changes the rendered output, which is exactly why it goes unnoticed. Your file is different and your document looks identical.

Then there is the part that does change meaning:

• Callouts (> [!note]) are an extension. A model that does not know them may keep the quote and drop the marker.
• Embeds (![[file]]) are Obsidian syntax, not standard markdown.
• Footnotes, raw HTML and custom frontmatter fields are all candidates for silent removal.

Anything the model cannot represent has nowhere to go on the way back out.

Why it matters more than it sounds

For a scratch file, none of this matters.

For a vault you have kept for years, it matters a great deal, and for three reasons.

It is invisible. Nothing errors. The document looks right. You find out when a callout you wrote two years ago has become a plain quote.

It is cumulative. Every save of every file the editor touches.

It contaminates version control and sync. A one-word edit produces a diff touching forty lines, so review becomes useless and sync conflicts multiply.

How to test your editor in two minutes

cp note.md note-backup.md
# open note.md, change one word near the end, save
diff note-backup.md note.md

If the diff shows only your change, the editor leaves files alone. If it shows reformatting elsewhere, it is re-serialising the document.

Do this before you point any new editor at a folder you care about.

What to look for instead

An editor that keeps the raw markdown as the source of truth and renders on top of it. The giveaway in the documentation is a mention of CodeMirror or a statement that the buffer holds plain text.

TypeFire's notes editor is built on CodeMirror for exactly this reason. Markdown renders live while the buffer stays raw, so callouts, embeds, footnotes, raw HTML and your own choice of bullet and emphasis characters survive untouched. It is also why a 10,012 file test vault, including plugin frontmatter and unusual encodings, could be opened with zero files modified and sha256 checked before and after.

The nicest editing experience in the world is not worth a vault that slowly stops being the thing you wrote.