Markdown Normalize Line Breaks

One line ending for the whole file

Markdown Normalize Line Breaks converts every line ending in a Markdown document to the Unix style, a single line feed (LF). Files that have passed between Windows, macOS and Linux machines, or that were assembled from copy and paste, often carry a mix of endings: carriage return plus line feed (CRLF) from Windows, a lone carriage return (CR) from very old Mac software, and LF from everything else. The text looks fine on screen, but the mixture causes noisy diffs, confuses some parsers and linters, and can make scripts that split on \n leave stray \r characters behind.

The tool also has one option, Trim trailing spaces, which removes spaces and tabs from the end of every line while it normalises the endings.

The three kinds of line ending

CRLF pairs are handled first and replaced with a single LF, then any remaining lone CR is replaced with LF. A CRLF never turns into two line breaks.

Runs locally in your browser

The normalisation is done by JavaScript on the page. Nothing is uploaded, there is no server call, and the tool keeps working if your connection drops after the page has loaded. That makes it suitable for internal notes, private drafts or configuration documentation you would rather not send anywhere.

Using the tool

1. Paste your Markdown into the Input Markdown editor, or use the Paste button in the header or under the editor. If you just want to see what the tool does, click Load sample; it fills the editor with a short document that uses CRLF endings and has trailing spaces and a trailing tab on some lines.
2. Decide on Trim trailing spaces. The checkbox is ticked by default. Untick it if you only want line endings changed.
3. Click Normalize (it appears in the header and below the input editor; both do the same thing).
4. Read the result in Normalized Output.
5. Click Copy to copy it, or Download to save normalized-markdown.md.
6. Clear empties both editors.

The three counters

Above the editors you will find Input lines, Output lines and Trailing spaces removed. The line counts treat CRLF, CR and LF all as line breaks, so they normally match: normalising endings does not add or remove lines. The third counter reports how many input lines end in spaces or tabs. It is computed from the input whether or not the checkbox is ticked, so read it as "lines that have trailing whitespace" rather than proof that they were trimmed.

When to tick Trim trailing spaces, and when not to

Trimming is useful in most documentation. Trailing whitespace is invisible, it triggers lint warnings, and it creates pointless changes in pull requests. But there are two cases where you should leave the box unticked:

• Hard line breaks. Markdown turns two or more spaces at the end of a line into a line break within the paragraph. Addresses, poetry and some tables of contents rely on that. Trimming removes those spaces and the lines will run together when rendered.
• Whitespace-sensitive code. Trimming applies to every line, including lines inside fenced code blocks. If a code sample must keep trailing spaces (for example a Markdown example that itself demonstrates hard breaks, or test fixtures), untick the option.

With the box unticked, only the line endings change and every other character stays as it was.

Typical situations

• Git shows every line changed. A teammate saved a README on Windows with an editor that rewrote the endings. Normalise it, commit, and the diff will only show real edits.
• A static site build warns about stray characters. Some generators and front matter parsers stumble over \r. Converting to LF removes them.
• Pasting from email or a PDF. Copied text often arrives with CR or CRLF. Normalising first makes later clean-up tools behave predictably.
• Preparing input for scripts. Command-line tools such as grep, sed or shell loops expect LF. A file with CRLF can make a match fail at the end of every line.

Things not to expect

• It does not convert to CRLF. The output is always LF. If a Windows-only tool needs CRLF, configure your editor or Git to convert on checkout instead.
• It does not remove blank lines or collapse them. Use Markdown Remove Empty Lines or Markdown Minifier for that.
• It does not touch leading indentation, tabs in the middle of a line, or non-breaking spaces.
• It does not change encoding. Characters stay as they are; only CR and LF are affected, plus spaces and tabs at line ends when trimming is on.

Limitations

• Trimming is not fence-aware. As noted above, trailing whitespace inside code blocks is removed too when the option is on.
• Only space and tab count as trailing whitespace. Other invisible characters, such as a non-breaking space or a zero-width space at the end of a line, are not removed.
• Clipboard permission. The Paste buttons need your browser's permission to read the clipboard. If it is denied, paste with your keyboard instead.
• Large files are limited only by your browser's memory and editor performance; no size cap is set in the code.

A quick check after normalising

Many editors show the current line ending in the status bar (often labelled CRLF or LF). Open the downloaded file and confirm it shows LF. In Git, running git diff after replacing the file should show only the lines where you trimmed whitespace, or nothing at all if the endings were the only difference and your Git settings ignore them.

Stopping mixed endings from coming back

Normalising a file fixes it once. If several people edit the same repository, the mix can return with the next commit from a differently configured machine. Two habits keep things stable. In Git, a .gitattributes file with a line such as *.md text eol=lf tells Git to store Markdown with LF endings regardless of the editor's behaviour. In your editor, set the default line ending for new files to LF; most code editors expose this as a single setting and show the current value in the status bar. With both in place, this tool becomes something you reach for when text arrives from outside the project, such as a pasted email or an exported document, rather than a routine chore.

Frequently Asked Questions