TSV Line Ending Converter
A TSV exported on Windows ends every line with \r\n. Read it with a naive Unix parser and the carriage return becomes part of the last field on every row — so active is really active\r, string comparisons fail, numbers won't parse, and a diff shows every row as changed. This detects what you have, reports whether the file is mixed, and rewrites the endings consistently.
How to use
- Drop the file rather than pasting it, if you can — pasting through the clipboard can normalise the endings before the tool ever sees them, which makes the detection report meaningless.
- Read the status line. It counts CRLF, lone LF, and lone CR separately and flags the file as mixed if more than one appears.
- Pick the target. LF for anything Unix-shaped: Git, Docker, most databases, most languages' default readers.
- Set the trailing newline if the consumer is fussy — POSIX says a text file's last line ends with a newline, and some loaders drop the final record without it.
Why mixed endings happen
Almost always because a file was edited in more than one place: exported from a Windows tool with CRLF, then appended to by a script that wrote LF. The result parses in most readers, which is exactly why it survives long enough to cause trouble later — a diff, a checksum comparison, or a strict loader eventually notices. When the status line says mixed, converting is the right move regardless of which target you pick.
Note that this operation is purely about the bytes between records. It does not touch tabs, quoting, or the contents of fields — a \r that lives inside a quoted field is left alone, because it's data rather than a line ending. That's the correct behaviour, and it's why a plain tr -d '\r' can be more destructive than it looks.
The Excel wrinkle
Excel on Windows writes CRLF and expects it back; Excel on macOS is happy with either. If a TSV opens in Excel with every row crammed into a single cell, line endings are usually not the cause — that's a delimiter or encoding problem, and adding a BOM is the usual fix. If instead you see an empty row between every data row, you have CRLF being interpreted as two line breaks, which converting to LF resolves.
FAQ
Does pasting into the box preserve the original endings?
Not reliably. Browsers normalise clipboard text and a <textarea>'s value is defined to use LF, so a pasted Windows file often reports as pure LF. Drop the file to get an honest reading — the file reader hands over the bytes as they are on disk.
What's the command-line version?
dos2unix f.tsv and unix2dos f.tsv if they're installed; otherwise sed -i '' $'s/\r$//' f.tsv strips CR from line ends only — note the $ anchor, which is what keeps it from deleting carriage returns inside fields.
Should I let Git handle this instead?
For files in a repository, yes — * text=auto plus *.tsv text eol=lf in .gitattributes normalises on commit and saves you doing it by hand. This page is for files passing through outside version control.
Why is CR-only still offered?
Because old Mac-era data files still exist in archives and some legacy Mac software still expects it. You will almost certainly never need it.
Privacy
100% client-side. No upload. See the privacy policy.