A line counter that runs in your browser counts every line in a block of text the moment you paste it, reporting total lines, blank lines, non-blank lines, and the length of the longest line, with nothing sent to a server. Counting lines is unambiguous only when the boundary rules are stated up front: 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 a single boundary rather than two, and a trailing newline creates a final empty line. An entirely empty input is the only case defined as zero lines. Once any content is present, the count is at least one. Mixed line endings are accepted in the same input, which matters when text has moved between Unix, Windows, classic Mac, terminal, and clipboard environments. These rules are what separate a reliable line count from a guess that drifts every time the source file changes hands.
The Line Counter tool applies these rules in a single browser pass. You paste, the four statistics update instantly, and the calculation never calls a remote service, so source code, logs, prose, lists, configuration, and subtitles can all be checked privately on the same page.
What a line counter actually measures
An online line counter does more than split text on every newline. A reliable one reports four separate statistics that together describe the shape of the text:
- Total lines — the count of every line produced after splitting on the stated boundaries, including empty segments created by trailing newlines.
- Non-blank lines — lines that contain at least one character after surrounding Unicode whitespace is trimmed.
- Blank or whitespace-only lines — lines whose characters are entirely spaces, tabs, or other whitespace that JavaScript trim removes.
- Longest line (code points) — the longest line measured in Unicode code points rather than UTF-16 code units, bytes, or visible columns.
Because the total always equals non-blank plus blank, the four numbers form a built-in cross-check. If the total does not match the sum of the other two, the tool has a bug; if it does match, the reader has a sanity check for free.
How to count lines of text online
- Open the Line Counter tool in your browser.
- Copy the text you want to count from its source — an editor, a chat window, a log file, a code repository, or any plain-text field.
- Paste directly into the editor; there is no upload step and no submit button.
- Read the four statistics under the editor as soon as the input lands: total lines, non-blank lines, blank or whitespace-only lines, and the longest line in code points.
- Compare the numbers with what your editor or command-line tool reports, paying attention to trailing-newline behavior and Unicode rules.
- Click Clear to wipe the input and return every statistic to zero when you are done.
The statistics update on every keystroke, so partial work in the editor is already countable. No account is required, no file is sent over the network, and the editor never displays a partial preview that might look complete.
Why boundary rules change the total
The single biggest reason two line counts disagree is the rule for the last boundary. Different editors describe lines as newline characters, as logical records, or as visual rows, and some suppress a final empty segment while others expose it. A counter that hides this choice cannot be reconciled with one that exposes it.
The boundary rules used by the tool are explicit and easy to verify against common inputs:
| Input as typed | Total lines | Non-blank | Blank | Note |
|---|---|---|---|---|
| (empty) | 0 | 0 | 0 | Defined zero-line case |
| alpha | 1 | 1 | 0 | No trailing boundary |
| alpha + LF | 2 | 1 | 1 | Trailing boundary creates an empty line |
| one CRLF only | 2 | 0 | 2 | Separator has an empty segment on each side |
| alpha + CRLF + beta | 2 | 2 | 0 | CRLF is one boundary, not two |
| alpha + CR + beta (classic Mac) | 2 | 2 | 0 | Lone CR is also a boundary |
Two consecutive trailing newline boundaries create two trailing blank segments rather than collapsing them. This matches what the text actually contains and avoids silent changes based on whether the last line happens to be empty. The implementation splits on CRLF before lone CR or LF so a Windows boundary is never double-counted.
Blank, non-blank, and longest line, explained
Distinguishing blank from non-blank lines is not the same as asking whether the line is empty. The rule is: trim the line using Unicode whitespace rules, and if nothing remains, the line is blank. A line of pure spaces, a line of tabs, or a line that mixes the two is blank. A line with spaces around a visible letter, such as " hello ", is non-blank because the letter survives the trim.
Whitespace-only lines are still part of the input: their original characters are not removed, and they continue to contribute to the longest-line length. That means a single 200-character line of spaces is reported as both a blank line and the longest line, which is the correct behavior when the longest-line metric is intended to reflect what was actually pasted.
The longest-line metric is labeled "code points" and the label is repeated under the results. This matters for three classes of text:
- Supplementary-plane emoji such as 😀 occupy two UTF-16 code units in JavaScript but count as one code point here.
- Decomposed accents like e followed by a combining acute accent count as two code points even though they render as a single visible grapheme.
- Family emoji joined with zero-width joiners contain several code points while appearing as one symbol.
Code-point length is not terminal width, not monospace cell count, not bytes, and not normalized text length. Tabs count as one code point regardless of how an editor expands them visually. Combining marks, variation selectors, and joiners each count as their own code points. The counter does not normalize Unicode, expand tabs, strip non-separator carriage returns, or change the pasted content before analysis.
When the input limit stops the count
The counter accepts up to 1,000,000 JavaScript UTF-16 code units as a browser memory and responsiveness guard. The size shown under the editor uses the same code-unit measurement, so the meter and the limit line up. Text exactly at the limit is processed in full.
If the input exceeds the limit by even one code unit, the entire analysis returns an error and every previous statistic disappears. The tool never counts a prefix and never silently truncates the remainder. This guard is separate from the longest-line code-point metric, so a supplementary-plane emoji can consume two units of the input allowance while contributing only one code point to the longest-line length. The distinction is intentional and disclosed on the page.
For larger inputs, the practical path is to split the source with a tool that keeps the line structure intact, count the parts, and add the totals together while checking that no part's boundary is split across the cut. A complementary walkthrough of file-level boundary rules is in the Count Lines in a File With Clear Boundary Rules guide.
Comparing line counts across tools and editors
When two line counts disagree, the difference is almost always one of three things: trailing-newline handling, blank-line definition, or whether the counter measures UTF-16 code units versus code points. Resolving the gap is a checklist:
- Confirm whether the other tool treats a final empty line as a line at all.
- Confirm whether it considers whitespace-only lines to be blank.
- Confirm whether its "longest line" metric is bytes, UTF-16 code units, code points, or visible columns.
- Confirm that both inputs use the same Unicode normalization, especially for combined accents and precomposed letters.
- Confirm the same line-ending interpretation: are CR, LF, and CRLF each one boundary, or does the other tool count CRLF as two?
The counter deliberately chooses one consistent rule and exposes it on the page rather than claiming every editor will display the same total. Because everything is local and deterministic, pasting the same sequence of UTF-16 code units into the tool produces the same statistics in any supported browser. For related needs, the same kind of live, browser-only analysis applies to word totals with the Word Counter.