Line Break Counter
Count line breaks, and detect whether a file uses Windows (CRLF), Unix (LF) or classic Mac (CR) line endings, byte by byte.
0
Line breaks
1
Total lines
0
Non-empty
0
Blank lines
How to use this tool
- Paste text into the box for an instant count of line breaks, blank lines and non-empty lines.
- Switch to 'Upload a file' to check which line ending convention a real file uses. This needs a file rather than pasted text, because a browser text box silently rewrites every line ending to the same character the moment you paste.
- The file view reports how many CRLF (Windows), lone LF (Unix, Linux, macOS) and lone CR (classic Mac) breaks are present, and flags the file as mixed if it contains more than one kind.
- Download the file re-saved with a single consistent line ending if you need to normalise it.
About this tool
A line break is not one character everywhere. Windows text files end each line with two bytes, a carriage return followed by a line feed (CRLF, "\r\n"). Unix, Linux and modern macOS use one byte, a line feed (LF, "\n"). Classic pre-2001 Mac OS used a lone carriage return (CR, "\r"). Mixing them inside one file is a common, hard-to-spot cause of broken diffs, git showing an entire file as changed, or a script that reads line by line and silently drops a line. This is also why pasting text into an online counter can never answer the question properly: the browser's own text box specification requires every line ending typed or pasted into it to be normalised to a single "\n" before your JavaScript ever sees it. There is no way to recover the original bytes from a paste. To report the real convention a file uses, this tool reads the file's raw bytes with the File API instead of routing it through a text box, counts each kind of line ending directly, and reports which one dominates, or flags the file as mixed if more than one appears. It also detects a UTF-8 byte order mark, a three-byte prefix some Windows editors add that is invisible in most text viewers but can break a script expecting the file to start with its first real character. Once the ending is identified, you can download the same file normalised to CRLF, LF or CR in one click. Everything happens locally using the File and Blob APIs built into your browser. The file you upload is read into memory for this one operation and is never transmitted anywhere.
Frequently asked questions
What counts as a line break?
A line break is the character sequence that ends one line and starts the next. Windows files use two characters (CRLF). Unix, Linux and modern macOS use one (LF). Old classic Mac OS used a different single character (CR). This tool's paste mode counts every LF, which is what a browser gives you regardless of how the text was originally saved; upload mode counts the real bytes.
Why do I need to upload a file to detect CRLF vs LF?
Because a browser's text box (the HTML <textarea> element) is specified to convert every line ending to a plain LF as soon as text is typed or pasted into it. That conversion happens before any webpage's JavaScript can inspect the original bytes, on every site, not just this one. Reading the file directly with the File API is the only way to see what was actually saved to disk.
What does 'mixed line endings' mean?
It means the file contains more than one kind of line break, for example some lines ending in CRLF and others in a lone LF. This usually happens when a file has been edited on both Windows and Unix-based systems, or merged from two sources, and is a common cause of a version control diff showing far more lines changed than were actually edited.
How do I convert a file to Unix (LF) or Windows (CRLF) line endings?
Upload the file, check the detected breakdown, then use the download buttons to save a copy with every line ending replaced by CRLF, LF or CR consistently. The conversion runs locally and produces a new file; your original upload is left untouched.
Is my file uploaded to a server?
No. The file is read into your browser's memory using the File API and processed entirely with JavaScript. It is never transmitted anywhere, which makes this safe for source code, configuration files, or exports containing sensitive data.