You move a text file from a Windows machine to a Mac, open it, and the whole thing is one endless line. Or a script that ran fine yesterday now throws an error on line one for no obvious reason. Or your git diff lights up every single line as changed when you only touched three. These all trace back to the same invisible culprit: line endings.
Every line in a text file ends with a hidden character that says “stop here, new line.” Different operating systems chose different characters for that job, and when a file uses one style but a tool expects another, things break in confusing ways. This guide explains what those characters are, the symptoms of a mismatch, what a BOM is, and how to convert a file to one consistent style in the line-ending converter without anything leaving your browser.
What are line endings, and why do they differ?
A line ending is an invisible character (or pair of characters) marking where one line stops and the next begins. The three styles are LF on macOS and Linux, CRLF on Windows, and a lone CR on classic Mac systems. They look identical on screen, but a tool built for one can misread a file written in another.
The names come from old typewriter mechanics. CR (carriage return) moved the carriage back to the left margin. LF (line feed) rolled the paper up one line. Early computers borrowed both terms, and the platforms split on which to use:
- LF (
\n): macOS and Linux. A single line-feed character. - CRLF (
\r\n): Windows. A carriage return followed by a line feed. - CR (
\r): classic Mac OS, before macOS. A lone carriage return, now rare but still lurking in old files.
None of these is wrong on its own. The trouble starts only when a file with one style meets a tool that assumes the other.
What are the symptoms of a line-ending mismatch?
The clearest signs are a file collapsing into one long line, line breaks appearing as visible junk characters, scripts failing on the first line, and git marking every line as changed. Any of these points to a file whose line endings do not match what the tool reading it expects, even though the text itself is fine.
Here is how each one tends to show up:
- The whole file is one line. An editor that only understands LF opens a CR-only file and finds no breaks it recognizes, so everything runs together. The text is intact; the breaks are just unreadable to that editor.
- Stray characters at line ends. You see
^Mor boxes where line breaks should be. That is a carriage return showing through because the tool expected plain LF and found CRLF. - Scripts break on line one. A shell script saved with CRLF can fail immediately, because the interpreter reads the trailing carriage return as part of the command and cannot find the program it names.
- Noisy git diffs. A teammate on Windows saves a file as CRLF, you are on a Mac expecting LF, and git reports every line as modified even though no real content changed. Code reviews drown in phantom changes.
If you are seeing any of these, the file’s content is almost always fine. Only the invisible endings are out of step.
Why developers hit this most
Cross-platform teams are where line-ending pain concentrates. One person commits from Windows, another from a Mac, and unless the repository pins a style, files flip back and forth and pollute the history. Build scripts, config files, and anything run by an interpreter are the usual victims, since those tools read endings literally. Settling on LF for code, which most version-control and deployment tooling assumes, heads off most of it.
What is a BOM, and when should I remove it?
A BOM, or byte order mark, is a few hidden bytes at the very start of a file that label its text encoding. UTF-8 files do not need one. When a BOM is present, some tools read those bytes as real content, which breaks scripts, configs, and anything that expects the first character to be meaningful.
The BOM was designed to flag a file’s encoding so software could read its characters correctly. For UTF-8, the most common encoding today, it is optional and usually best left off. The problem is that not every tool knows to skip it:
- A config file with a BOM can fail to parse, because the parser sees invisible bytes before the first real setting.
- A script can break on the first line, since the interpreter reads the BOM as part of the opening command.
- A web page can show a stray character or a blank gap at the top, where the browser rendered the mark as content.
Remove the BOM when a tool chokes on a file’s first line for no visible reason, especially scripts, JSON, YAML, and other config formats. Keep your files as plain UTF-8 without a BOM and most modern tools stay happy.
How do I convert a file to one consistent style?
Load the file, choose your target style (LF, CRLF, or CR), and convert. The tool rewrites every line ending to the one style you picked and can strip a leading BOM at the same time. Your actual text is untouched, so only the invisible endings change. Save the result back to your computer when it is done.
A short decision guide for which style to pick:
| Use case | Target style |
|---|---|
| Code, scripts, anything in git | LF |
| Files for older Windows-only tools | CRLF |
| Legacy classic-Mac files | CR (rare) |
When in doubt, LF is the safest default. It is what version control, deployment pipelines, and most command-line tools expect, and modern editors on every platform display it correctly. Reach for CRLF only when a specific Windows program demands it.
The practical workflow:
- Load the text file into the converter.
- Pick your target line-ending style (LF for most cases).
- Turn on BOM removal if a tool was tripping over the file’s first line.
- Convert, then save the file back to your machine.
Because the conversion only swaps end-of-line characters, the file reads identically when you reopen it. The difference is that the tools consuming it now agree on where each line ends.
Working safely with your files
The line-ending converter runs entirely in your browser. Your file is read on your own device, converted locally, and saved straight back to your computer. Nothing is uploaded to a server, which matters when the file is source code, a private config, or a document you would rather not send anywhere.
It is worth keeping the original until you have confirmed the converted file behaves. Reopen it in the tool that was failing and check the symptom is gone, whether that was a collapsed file, a broken script, or a noisy diff. Once it works, you can convert your file and move on, with a clean, consistent set of line endings that every tool can read the same way.