Skip to content
AZ Tools

Line Endings & BOM Converter

Counts CRLF, lone CR, and lone LF separately before normalising, so you can spot files that mix conventions (a common cause of dirty git diffs or Bash scripts that fail on Windows). Output bytes are reported with the BOM included, so you know exactly what will land on disk. All processing is local in your browser.

Target line ending
UTF-8 BOM
Output
Input stats
  • LF count1
  • CRLF count1
  • Lone CR count0
  • Total lines3
  • Output bytes (UTF-8)28
  • Had BOMNo

Mixed-ending files usually mean the source was edited across platforms — normalising fixes most "why does my diff explode" headaches.

How to use

  1. Paste text or drag a file's contents into the input.
  2. Pick the target line ending (LF for Unix/macOS, CRLF for Windows, CR for legacy Mac).
  3. Choose the BOM policy and copy the output.

Frequently asked questions

When should I keep the BOM?
Some legacy Windows tools and a few Excel CSV imports rely on it. For everything else (especially shell scripts, JSON, and source code in modern build chains), strip it.
What's a mixed-ending file?
Any file that contains more than one of LF/CRLF/CR. Common when text gets edited across platforms or when generators concatenate fragments from different sources. Normalising to a single style makes git diffs and downstream parsers behave.
Why does git show my whole file as changed?
Because every line differs: the file was committed with one line ending and saved with another, so there is no unchanged line left to anchor the diff. Normalise once, commit that, and set the repository's line-ending policy so the conversion is not reapplied on the next checkout.
Does the last line need a newline at the end?
For most Unix tooling, yes — a line is considered terminated by its newline, which is why diffs call out "No newline at end of file" and why concatenating two files without it glues the last line of one to the first line of the next. It is a separate question from which ending style you use.

Related tools