Line Endings & BOM Converter
Convert between LF, CRLF, and CR line endings and add or remove a UTF-8 BOM — with per-style counts so you can see how mixed the input was.
- 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
- Open a file (or drop it on the input) to see its real line endings; pasted text works for conversion.
- Pick the target line ending (LF for Unix/macOS, CRLF for Windows, CR for legacy Mac).
- Choose the BOM policy and copy the output.
About this tool
ShowHide
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. The counts need the file itself: a browser text box turns every CRLF and lone CR into LF the moment text is pasted or typed into it, so pasted text is converted correctly but its original endings are gone, and only an opened or dropped file is counted as it is on disk. The counts are the diagnosis, not just decoration. A file with both CRLF and LF is what makes a whole file show as changed in git; a lone CR belonged to classic Mac OS and today almost always means a file was cut mid-sequence or written by something confused. Fixing it here is the alternative to arguing with core.autocrlf on every machine that touches the repository.
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
.gitattributes Tester
Paste a .gitattributes and a list of paths to see every attribute git ends up setting on each path, and which line — or which macro — set it.
Developer
File Encoding Detector
Upload any text file and detect its encoding — UTF-8, UTF-16 LE/BE, UTF-32, Latin-1, ASCII — with BOM detection, byte signal analysis, and a hex preview.
File
Text Encoding Converter
Open text files in legacy encodings (EUC-KR, Shift_JIS, Windows-1252…) as readable UTF-8.
File
Mbox Archive Viewer
Split a .mbox archive in your browser: message boundaries, decoded headers, MIME structure, threads and duplicate Message-IDs. Nothing is uploaded.
File
CSV ↔ JSON Converter
Convert CSV to JSON and JSON back to CSV, with a delimiter option.
File
Excel (XLSX) to CSV, JSON & Markdown
Open an .xlsx workbook in the browser and export any sheet as CSV, JSON or a Markdown table — the file never leaves your device.
File