Why line endings differ: the two-character history
The convention predates computers: on a teletype, carriage return (CR) physically slid the print head back to the left margin, and line feed (LF) rolled the paper up one line — two separate mechanical actions, two separate control characters. Early operating systems each picked a convention: Unix decided one character was enough and kept LF; the systems that led to Windows kept the faithful two-character CR+LF sequence; classic Mac OS (pre-2001) used lone CR. Unix's choice won everywhere Windows isn't: Linux, macOS, the web, and git's internal storage all speak LF. The result is that any file edited on both sides of the divide tends to accumulate both endings — which is the "mixed" state this tool highlights, and the only state that reliably causes trouble.
| Ending | Bytes | Escape | Where |
|---|---|---|---|
| LF | 0A | \n | Linux, macOS, git, the web |
| CRLF | 0D 0A | \r\n | Windows; also required by many network protocols (HTTP headers, SMTP) |
| CR | 0D | \r | Classic Mac OS — rare today, but survives in old exports |
Mixed endings in version control and diffs
The classic symptom: a diff claims every line of a file changed when you edited three. What happened is an editor or tool rewrote the line endings wholesale, so every line's bytes differ even though no visible character did. Related symptoms from the same cause: a shell script that fails with a cryptic "command not found" because the interpreter path ends in an invisible \r; a merge conflict on every line; a linter flagging files nobody touched. The cure has two halves — normalize the files (what the converter above does) and configure your version-control system and editors to agree on one ending per file type going forward, so the mix doesn't regenerate. Most teams settle on LF in the repository, letting individual tools convert at checkout if they must.
The BOM: three invisible bytes at the front
A byte order mark is a Unicode signature some Windows tools write at the very start of a UTF-8 file: the bytes EF BB BF, which display as nothing. It's legal but frequently unwelcome — shells refuse a script whose first bytes aren't #!, some JSON parsers reject it, and concatenating BOM-ed files sprinkles the marker mid-stream. When you drop a file above, the tool reads raw bytes, so it detects a UTF-8 BOM reliably (and recognizes UTF-16 BOMs, decoding those files accordingly); the strip option removes it on output. Pasted text can't carry this information faithfully — the clipboard has usually already dealt with it — which is why the file path is the accurate one.
Frequently asked questions
What does git's autocrlf setting actually do?
Generically: version-control systems can convert line endings automatically at the boundary between the repository and your working files. In git's case the core.autocrlf setting has three modes — convert to CRLF on checkout and back to LF on commit (the traditional Windows setting), convert only on commit (input), or don't touch anything (false). Modern practice increasingly prefers declaring endings per file type in a .gitattributes file committed to the repository, because it applies to every contributor identically instead of depending on each machine's configuration. Either way, the repository's canonical copies are best kept LF — which is what the converter above produces.
Which ending do I actually want?
LF, unless you have a specific reason otherwise. Code, configs, and anything in version control: LF — every modern editor on Windows handles LF files fine. The genuine CRLF cases: files consumed by old Windows-only tools (pre-2018 versions of Windows' built-in text editor, some legacy batch processing), and .bat/.cmd scripts, which can misbehave with LF. Lone CR: only if you're feeding a museum piece. When in doubt, this page's default — convert to LF, strip BOM — is the safe answer.
Why does the tool say my pasted text is all LF when the file is CRLF?
The clipboard normalized it. Browsers and operating systems routinely convert line endings during copy-paste, so by the time text lands in the box the \rs may already be gone. That's not the tool being wrong — it's faithfully reporting the text it received. For a byte-accurate reading of what's really in the file, use the file drop, which bypasses the clipboard entirely.
Is my file uploaded when I drop it here?
No. The FileReader API hands the file's bytes directly to JavaScript in your tab — there's no upload, no server, and the page keeps working offline. You can verify in your browser's DevTools Network panel: dropping a file produces no request.