Why Markdown eats your line breaks, and what to do about it

You type an address, four lines, one Enter between each. It renders as one long line. You try again with the same result, and start to suspect the editor is broken. It is not — this is the specified behaviour, and it has been since the beginning.

Where it comes from

Markdown was designed in 2004 to make plain-text email and Usenet posts render nicely as HTML. Plain text of that era was hard-wrapped at about 72 columns, because terminals were, so a paragraph in a source file looked like this:

This is a single paragraph that has been hard-wrapped by the
author's editor at seventy-two columns, as was the convention,
and it is all meant to be one paragraph.

Three lines, one paragraph. If Markdown had honoured every newline, every wrapped paragraph would have rendered as a stack of short broken lines. So a single newline became a space, and only a blank line started a new paragraph. For its purpose, exactly right.

Where it genuinely hurts

For ordinary prose the behaviour is invisible and fine. It becomes a real obstacle whenever the line is the unit of meaning:

• Poetry. Line breaks are the form. A poem reflowed into a paragraph is no longer a poem.
• Song lyrics, for identical reasons.
• Addresses, on a title page, a copyright page, or a letter.
• Dialogue in scripts, where speaker and line are separate.
• Any short list you do not want bulleted — a cast list, a set of credits.

The four workarounds

Two trailing spaces

The original syntax. End a line with two spaces and it becomes a <br>:

Roses are red··
Violets are blue

It works nearly everywhere and it is genuinely awful. The syntax is invisible — you cannot see it, you cannot tell a line that has it from one that does not, and any editor configured to trim trailing whitespace on save will silently delete it. Many are configured that way by default, and many teams enforce it in a linter.

A trailing backslash

Roses are red\
Violets are blue

Visible, survives whitespace trimming, and specified in CommonMark — so it works in most modern processors. It does not work in some older ones, and it leaves a backslash at the end of every line of your poem, which is not the plain-text file anybody wanted.

An HTML break tag

Roses are red<br>
Violets are blue

Explicit and reliable, wherever raw HTML is allowed — which is not everywhere, since some processors strip it. And it is HTML in your Markdown, which for a manuscript is a meaningful loss.

Turn the behaviour off

Many processors have an option to treat a single newline as a break: hard_line_breaks in Pandoc, breaks: true in markdown-it. GitHub comments, Slack and most chat tools have it on permanently, which is why the rule surprises people — most Markdown they type day to day already behaves the way they expect.

This is the cleanest option when it is available, because the file stays clean. The catch is that the file's meaning now depends on a setting, so the same source rendered elsewhere loses the breaks.

Which to use

For a manuscript that will be rendered by one known tool, turning the behaviour off is best. For something passing through several hands, the backslash is the reasonable compromise. Two trailing spaces should be avoided in anything you intend to keep.

The version that needs no workaround

A renderer built for books rather than for comment threads can simply make the sensible default. In bukpress, one Enter is a real line break — a poem is typed as a poem, an address as an address, and the file has no invisible whitespace, no backslashes and no HTML in it.

The 2004 rule solved a 2004 problem. Anything writing a book today is not receiving hard-wrapped Usenet posts, and inheriting the workaround along with the syntax was never obligatory.

The related case — breaking a *page* rather than a line — has the same shape and a different answer: see how to control page breaks in Markdown.