Your Markdown editor shouldn't rewrite bytes you didn't touch

Open a Markdown file in most editors, change a single word, and save. Then run git diff. If you’re unlucky, you’ll see twenty lines changed instead of one — list markers swapped, headings re-spaced, your hard line breaks “tidied,” a trailing newline added or removed. You changed one word. The editor changed your file.

That’s the quiet tax of tools that treat your document as their data model instead of plain text. This post is about why that tax is worse than it looks, and what the alternative is.

What “byte-fidelity” actually means

A Markdown file is just bytes: characters, spaces, and newlines. “Byte-fidelity” means a save touches only the bytes you edited and leaves every other byte — your CRLFs, your BOM, your trailing spaces, your chosen list style — exactly as it found them. Edit one paragraph, and the diff is one paragraph. Nothing else moves.

It sounds obvious. Almost nothing does it.

Why invisible reflow costs you

The damage isn’t cosmetic — it compounds everywhere plain text is supposed to be an advantage:

• Code review becomes noise. A one-line fix buried in a forty-line reflow is a reviewer’s nightmare. They can’t see what you changed, so they rubber-stamp it — or bounce it back.
• git blame lies. Every line now “belongs” to whoever last opened the file, not whoever wrote the sentence. Your history dissolves.
• Merges break. Two people who edited different paragraphs now conflict across the whole file, because both editors reflowed everything around their change.
• Trust erodes. Once you’ve watched a tool silently rewrite a file, you start saving less, exporting more, and reaching for the “show source” button you shouldn’t need.

The throughline: a tool that reformats freely turns plain text — the most durable, portable, version-controllable format there is — into something you can’t actually diff.

What it looks like when a tool respects your file

The fix isn’t a setting. It’s an architecture: plain text is the document, and the pretty view is only a projection over it. Render the marks away while you write, sure — but when you save, write back exactly what changed and not one byte more.

In practice that means a one-word fix shows up as a one-word diff:

@@ -12 +12 @@
-teh roadmap
+the roadmap

One line in, one line out. No reflow, no surprises, no “normalization” you never asked for. Your git diff stays honest, your blame stays accurate, and your files remain yours — readable and identical on any machine, in any editor, ten years from now.

That’s the whole idea behind Constly: a WYSIWYG Markdown editor that renders as you type and still never rewrites a byte you didn’t touch. It’s free to use — try it and run git diff yourself.