Normalize Line Breaks

Rewrite mixed line endings to Unix LF, Windows CRLF, or classic CR.

What Normalize Line Breaks helps you do

Rewrite mixed CRLF, LF, and classic CR endings to a single line-ending style before commit, CI, or handoff between Windows, macOS, and Linux teams. It prevents noisy diffs and parsers that expect one convention. The transformation is deliberately narrow: only the line endings change.

Text is processed entirely in your browser. Nothing is uploaded or stored after your session.

How it works

Every CRLF, CR and LF sequence is first replaced with a single LF. The text is then rewritten with the chosen ending: LF stays as is, CRLF replaces each LF with a carriage return and line feed, and CR replaces it with a carriage return. No other characters are touched.

How to use Normalize Line Breaks

  1. Paste text with mixed endings and choose LF, CRLF, or CR output.
  2. Review the preview; note that the textarea may not show the difference between CRLF and LF.
  3. Copy or download the normalized text before saving it to disk or Git.
  4. Add a repository rule so the file stays consistent.

When to use it

  • Normalize README or script files before opening a pull request.
  • Fix CSV or log exports that picked up Windows CRLF on upload.
  • Prepare text for tools that require Unix LF only.
  • Remove a whole-file diff caused by an editor changing line endings.
  • Make a shell script safe to run on Linux after editing on Windows.
  • Normalize a fixture before comparing it with a golden file.

When not to use it

  • Do not use it to change indentation, trailing spaces or encoding; it only changes line endings.
  • Do not expect the browser preview to reveal whether CRLF survived; download the file.
  • Do not normalize a binary file; it is a text operation.

Example

A shell script edited on Windows opens with CRLF and fails on a Linux runner with a bad interpreter error. Normalizing to LF and committing the file fixes the script, and a .gitattributes rule keeps future edits in LF.

What you can do with Normalize Line Breaks

  • Detect and unify mixed CRLF, LF and CR endings.
  • Output Unix LF, Windows CRLF or classic CR.
  • Leave the rest of the text unchanged.
  • Copy the normalized text or download it as a file.
  • Prepare text for a repository or a tool with a strict newline rule.
  • Keep the input in the browser.

Example: stop a whole-file diff

Paste the file content and choose LF. The mixed endings are unified, and only the line breaks change.

Download the result rather than copying from the preview if you need CRLF; browsers may display all endings the same way in a textarea.

Commit the normalized file, then add a .gitattributes rule or an editor setting so the endings do not drift back on the next save.

What to know before you start

  • Only line endings change; indentation, encoding and trailing spaces are untouched.
  • The textarea may not visually distinguish CRLF from LF.
  • It does not set repository attributes or editor settings for you.
  • Binary files are not supported.
  • A trailing newline at the end of the file is preserved as it was.

Common mistakes

  • Copying from the preview instead of downloading, then wondering why CRLF disappeared.
  • Normalizing one file while the repository still forces the other convention.
  • Assuming a diff is a content change when it is only a line-ending change.
  • Applying the tool to a binary or minified file where the newline style does not matter.
  • Forgetting that some tools accept CRLF and others require LF.
  • Assuming a line-ending change is invisible to every build tool.

Troubleshooting

If the pasted text looks unchanged, the textarea may render both endings the same; download the file and inspect it in an editor that shows line endings.

If a script still fails after normalization, check the shebang and permissions, not only the newline.

If Git keeps converting the file, add a .gitattributes rule or check the core.autocrlf setting.

If the output has an extra blank line, the source may end with a newline that was already there; normalization does not add or remove trailing lines.

If a tool rejects the file, confirm which ending it expects; LF is the usual choice for servers and containers.

If a file has no final newline, normalization does not add one; some tools require a trailing newline, which is a separate fix.

If the editor keeps changing the file back, its save setting is overriding the result; set the editor to preserve or use LF.

Related standards and documentation

  • POSIX text files use LF as the line terminator.
  • Git's .gitattributes can enforce a consistent line-ending policy per repository.
One convention, no other changes
  • LF for Unix and containers.
  • CRLF for Windows text files.
  • Download to verify the ending.

Frequently Asked Questions