Free Line Ending Converter — Switch Between LF (Unix) and CRLF (Windows)

A line ending is the invisible character (or characters) that marks where one line stops and the next begins. The two that matter today are LF (a single line-feed, used by Unix, Linux, and modern macOS) and CRLF (a carriage-return followed by a line-feed, used by Windows). A third, a lone CR, was used by classic Mac OS and still turns up occasionally. They look identical on screen — the difference is in the bytes — which is exactly why mismatched line endings cause bugs that are maddening to diagnose: the text looks fine, but a program reading the bytes behaves differently.

This converter normalises a block of text to whichever style you choose. It reads what you paste, replaces the line-ending sequences consistently, and gives you back clean output — entirely in the browser, with no upload. That last point matters because line-ending problems often involve source code, configuration, or scripts you would rather not paste into a server-side service. Here the bytes are transformed locally and never leave your machine.

The classic symptom of a line-ending mismatch is a shell script that fails with a confusing error. A Bash script saved with Windows CRLF endings carries a trailing carriage return on every line; the shell tries to execute an interpreter path with an invisible CR appended and reports something like "bad interpreter: No such file or directory," or a command "not found" that plainly exists. Converting the file to LF fixes it instantly. The same class of problem hits Dockerfiles, entrypoint scripts, cron entries, and any file that a Unix system parses line by line.

The other place this bites is version control. If a file's line endings flip — because a teammate's editor saved CRLF where the repo uses LF — git can show the entire file as changed even though not a single visible character differs. That produces enormous, meaningless diffs that bury the real change and make code review painful. Normalising line endings before committing keeps diffs honest. Git's own autocrlf setting and a gitattributes file are the durable fix, but a quick manual conversion is often what you need to clean up a specific file or a snippet right now.

Beyond scripts and git, consistent line endings keep data files parsing predictably — CSVs moving between Windows and Unix systems, log files concatenated from mixed sources, and text fixtures in a test suite. Choosing one convention and converting to it removes a whole category of "works on my machine" surprises. For most modern, cross-platform work the safe default is LF; convert to CRLF only when a specific Windows tool or a legacy system requires it.