Skip to content
Lizely

Line Counter

Count total, non-blank, and blank lines plus the longest line without uploading your text.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Type or paste text into the editor; no upload or submit action is needed.
  2. 2.Read total, non-blank, blank or whitespace-only, and longest-line code-point counts.
  3. 3.Check the stated newline and Unicode rules when comparing the result with an editor or command-line tool.

About Line Counter

Line Counter analyzes the line structure of text directly in your browser. Paste source code, logs, prose, lists, configuration, subtitles, or any other plain text into the editor and the statistics update immediately. The result reports total lines, non-blank lines, blank or whitespace-only lines, and the length of the longest line. No account is required, no text is uploaded, and the calculation does not call a remote service. Clear removes the entire input and returns every statistic to zero. Line counting can be ambiguous unless the boundary rules are stated, so this tool defines them explicitly. An entirely empty input contains zero lines. Once the input contains any content, it contains at least one line. A line feed (LF), a carriage-return plus line-feed pair (CRLF), and a lone carriage return (CR) each create one line boundary. CRLF is treated as one boundary, not two. Mixed line endings are accepted in the same input, which is useful when text has passed between Unix, Windows, classic Mac, terminal, and clipboard environments. A newline boundary at the end of the input creates a final blank line. For example, alpha with no newline is one non-blank line. The text alpha followed by one LF is two total lines: the alpha line and an empty trailing line. A file containing only one CRLF is two blank lines, because the separator has an empty segment on each side. Two consecutive trailing newline boundaries create two trailing blank segments. This behavior follows the visible split structure and is never silently changed based on whether the last line contains text. β€œNon-blank” means a line contains at least one character after surrounding Unicode whitespace is trimmed. A line containing only spaces, tabs, or other whitespace recognized by JavaScript trim is counted as blank or whitespace-only. Its original characters are not removed from the input, and they still contribute to longest-line length. A line with spaces around a letter is non-blank. The total count always equals non-blank plus blank lines, providing a simple cross-check for every result. Longest-line length uses Unicode code points rather than JavaScript UTF-16 code units or user-perceived grapheme clusters. This distinction matters for emoji and combining text. A supplementary-plane emoji such as πŸ˜€ occupies two UTF-16 code units but counts as one code point here. A decomposed accented letter such as e followed by a combining acute accent counts as two code points even though it may render as one visible grapheme. A family emoji joined with zero-width joiners likewise contains several code points while appearing as one symbol. The interface labels the metric β€œLongest line (code points)” and repeats this limitation below the results so it does not imply visual-column width. Code-point length is also not terminal width, monospace cell width, bytes, or normalized text length. Tabs count as one code point even though editors may display them as multiple columns. Combining marks, variation selectors, and joiners each count as their own code points. The tool does not normalize Unicode, expand tabs, strip carriage returns that are not separators, or change the pasted content before analysis. Input is limited to 1,000,000 JavaScript UTF-16 code units as a browser memory and responsiveness guard. The counter shown under the editor uses the same code-unit measurement as that limit. Text exactly at the limit is processed. If the input exceeds the limit by even one code unit, the entire analysis returns an error and all previous statistics disappear; the tool never counts a prefix or silently truncates the remainder. This guard is separate from the longest-line code-point metric, so an emoji can consume two units of the input allowance while contributing one code point to longest-line length. The distinction is intentional and disclosed. The analysis is a shared pure function used by both the production interface and the isolated tests. Tests cover empty input, single lines, LF, CRLF, lone CR, mixed endings, one and multiple trailing newlines, whitespace-only lines, content surrounded by whitespace, supplementary emoji, combining marks, joined emoji, the exact input boundary, and rejection one unit beyond it. The implementation splits on CRLF before lone CR or LF so a Windows boundary cannot be double-counted. It then makes one pass over the resulting lines to classify whitespace and compute the maximum Array.from length in code points. This focused tool does not provide an optional numbered preview. Omitting that preview avoids creating hundreds of thousands of browser elements for a large one-line-per-character input and, importantly, means there is no hidden preview cap that could make a partial display look complete. Use the editor itself to inspect the original text, and use the four complete statistics for the accepted input. The tool also does not count words, sentences, bytes, visual columns, paragraphs, wrapped display rows, or editor-specific soft wraps. A long line that visually wraps inside the textarea remains one logical line unless the text contains an actual LF, CRLF, or CR separator. For word and character totals, use the related dedicated counters. For reliable comparisons between files, ensure both files use the same Unicode normalization and understand whether the other program counts a trailing empty line. Some editors describe lines as newline characters, some report logical records, and some suppress a final empty segment. This counter deliberately chooses and exposes one consistent rule rather than claiming every editor will display the same total. Because everything is local and deterministic, entering the same sequence of UTF-16 code units produces the same statistics in supported browsers.

Methodology & sources

Empty input returns zero lines. Otherwise text is split with the regular expression CRLF | CR | LF, ordered so CRLF is one separator. Split segments are retained, including an empty segment after every trailing newline. A segment is blank when JavaScript trim returns an empty string; non-blank plus blank always equals total. Longest-line length is Array.from(line).length, which counts Unicode code points rather than UTF-16 code units, grapheme clusters, bytes, or display columns. The 1,000,000-input limit is measured separately with JavaScript string length in UTF-16 code units. At-limit input is fully analyzed; over-limit input returns only an error and no partial statistics. Scope excludes soft-wrap rows, numbered preview, normalization, tab expansion, words, sentences, bytes, and visual terminal width.

Frequently asked questions

Does a trailing newline create another line?
Yes. Each LF, CRLF pair, or lone CR creates one boundary, and a boundary at the end produces a final blank line. Empty input is the only case defined as zero lines.
How are blank and non-blank lines distinguished?
A line is blank when trimming its Unicode whitespace leaves no content. A line containing only spaces or tabs is blank; a line containing a visible or non-whitespace character is non-blank.
What does longest line in code points mean?
Supplementary emoji count as one code point even though JavaScript stores them in two UTF-16 code units. Combining marks and zero-width joiners count separately, so this metric is not grapheme count or visual terminal width.
What happens above the input limit?
Text over 1,000,000 UTF-16 code units is rejected in full. The tool hides old statistics and reports an error; it does not truncate or return a partial count.

Related tools

Text Tools guides

View all