Line Ending Converter — LF, CRLF, CR

Guide

About Line Ending Converter

Convert between LF (Unix), CRLF (Windows), and CR (classic Mac) line endings. Detects the current style and reports counts for each variant. Useful when a file mixes line endings, when a script expects one specific style, or when you cannot find why a parse fails.

Why line endings still bite

Three operating systems, three conventions. Most modern tools handle all three, but the cases where they don’t are the ones you remember:

Bash scripts with CRLF endings — fail with “bad interpreter”
Java property files mixing styles — values include \r literally
Diff noise — a file converted between editors shows every line as changed
CSV imports — Excel saves CRLF; some parsers double-count

Quick detection

The tool’s header shows: “172 LF, 0 CRLF, 0 CR — Unix style”. A mixed file shows the count of each. Convert to a uniform target with one click.

Common workflows

Fix a CRLF Bash script. Convert to LF, redeploy, no more interpreter errors.

Normalize before diff. Convert both files to LF, diff. Whitespace-only differences vanish.

Prepare for a Windows tool. Convert to CRLF for tools that explicitly require it.

Audit a teammate’s export. Different OS, different default. Detect-and-convert keeps the repo consistent.

Why one click matters

The conversion is a one-liner in shell (tr -d '\r', sed -i 's/$/\r/'), but having to remember the magic invocation under pressure is friction. A click is faster.

Frequently asked questions

Which line ending should files use?

LF for source code (the universal convention; git normalizes to LF). CRLF is the Windows native default but most modern tooling handles both. Pure CR is dead (classic Mac, pre-2001).

Why does my script fail with "bad interpreter"?

Almost always CRLF in the shebang line. The kernel reads #!/bin/bash\r as the interpreter path, which doesn't exist. Convert to LF.

Mixed endings?

The detector reports if the file mixes LF, CRLF, and CR. Pick a target style and convert; the output is uniform.

What about line endings inside strings?

Treated as line endings for conversion. If you want to preserve embedded \\n / \\r escapes literally, use String Escape first.

Git's autocrlf?

Git can normalize on commit / checkout based on core.autocrlf. The tool here is for ad-hoc conversions outside git, or for files git mishandled.

Will the tool change the byte count?

Yes — CRLF is 2 bytes per line ending, LF is 1, CR is 1. The file size shifts accordingly.

Related tools

Last updated: 2025-01-15