Line Counter

A line counter reports how many lines a piece of text has. The tool above runs the count in your browser; nothing leaves your machine. The interesting question is what you mean by “line” — most counter disagreements are about edge cases.

The conventions

The tool above reports the first two side by side, plus a breakdown:

• Total lines — content lines, the count most modern tools report.
• Line breaks (wc -l) — the terminator count.
• Non-blank, Empty and Whitespace-only lines — how the total splits up.
• Longest line and average characters per line.

For most use cases, “content lines” is what people mean by “how many lines.”

CRLF vs LF

A CRLF line ending (\r\n, Windows) consists of two characters but represents one line break. A correct counter treats \r\n as a single terminator, not two.

Different counts:

Input (Windows file):
"Hello\r\nWorld\r\n"

Naive byte split on \n:
  3 lines (Hello\r, World\r, "")

Correct CRLF-aware count:
  2 lines (Hello, World)

Some tools split on \n only and count \r as part of the line content — visually correct, but then Hello\r appears as a line “ending in \r” which is confusing. The tool above normalizes CRLF to LF before counting.

Trailing newline

Input A: "Hello\nWorld"      (no trailing newline)
Input B: "Hello\nWorld\n"    (with trailing newline)

`wc -l` count:
  A → 1 line  (only one \n)
  B → 2 lines (two \n)

Content count:
  A → 2 lines (Hello, World)
  B → 2 lines (Hello, World — empty trailing line not counted)

The Unix convention is “files end with a newline.” A file ending without \n is technically malformed by some POSIX standards; modern tools tolerate it. The trailing-newline difference shows up in git diff (the “no newline at end of file” warning) and explains why two visually identical files can have different line counts.

Empty lines

Input:
"Hello\n\nWorld\n"

Total content lines: 3 (Hello, "", World)
Non-empty content lines: 2 (Hello, World)

Empty lines (just \n) and whitespace-only lines ( \n or \t\n) count differently depending on the tool’s definition of “non-empty.”

Programming use cases

Line counts are used for:

• Code metrics. “How many lines of code in this file?” Usually means non-empty, non-comment content lines (cloc, scc, tokei).
• Diff sizing. git diff --shortstat shows insertions/deletions in lines.
• Log analysis. “How many log entries?” Counting lines in a log file is a quick approximation if each entry is one line.
• Data integrity checks. “Did we lose rows in the export?” Compare line counts between source and destination.

Each use case has its own definition. Don’t argue about line counts without specifying the convention.

Lines vs records

For data files, a “line” might not equal a “record.” NDJSON (newline-delimited JSON) puts one record per line, so line count = record count. CSV with quoted multi-line cells has fewer records than lines:

name,description
"Alice","First record
spans two lines"
"Bob","Second record"

Line count: 4 (header + 2 data lines split by the embedded newline + 1). Record count: 3 (header + 2 records).

For records, parse with a CSV-aware tool, not a line count.

Words vs lines vs characters

Three different counts that often co-appear:

Each is useful for a different question. “How long is this?” is ambiguous; pick the relevant unit.

Common pitfalls

• CRLF assumed to be LF. A Windows-origin file run through a \n-only counter has every line look “normal” except its content silently includes a trailing \r.
• No trailing newline. A file that’s missing the final \n may have a smaller wc -l count than expected. If your tool depends on line count, normalize the file.
• Different wc -l outputs across systems. GNU wc and BSD wc are mostly identical; some embedded wc clones differ on edge cases.
• Text encodings. A UTF-16 file run through a UTF-8 line counter has every other byte being a null, which doesn’t break line counting (newlines are still detectable) but can confuse line-by-line tools.

For other text statistics, see character counter, word counter.