Line Counter

Most line counters hand you one number and stop, but this one goes further. Paste your text and you get the count broken out the way it actually matters, the total, the lines that have real content, and the blank ones, and then the part almost no free counter bothers with: how long your lines actually are. You get the longest, the shortest and the average, and the two extremes come with their line numbers so you can jump straight to them. Turn on line numbering and it prefixes every line with its number, ready to copy or download. It all runs live as you type, entirely in your browser. Nothing is uploaded, nothing is stored, and there's no size cap. A six-line note or a 50,000-line log both count the same way, instantly.

This is the problem that sends most developers to a line counter, and the one a plain counter can't help with. Your linter fails the build because a line is over 120 characters, and now you're scrolling a file squinting for it, and a total-line count does nothing to help. So this tool measures every line and reports the longest one with its number, something like line 42 at 137 characters, and you go straight there instead of hunting. That is the difference between a counter and an analyzer, and it's the whole reason we built the length stats in.

The average line length is a fast read on a whole file. A high average usually means dense, wrapping paragraphs that want breaking up. The shortest non-empty line catches the stray one-character row you left behind by accident. Length is measured in characters and does not count the line break itself, which is exactly what a "keep lines under 80" or "max 100 chars" rule is checking against.

Sometimes you don't want a count, you want the text back with every line numbered. You're reviewing a config with a coworker in chat and need to say "change line 14." You're quoting a snippet in a bug report. Flip on Add line numbers and every line gets its number, and you copy the whole block or download it as a plain .txt file.

The numbers right-align by default, so 9, 10, and 100 stack cleanly down the left edge instead of jittering. You pick the separator to match wherever you're pasting, a colon, a dot, a pipe, or a tab. Working against an array or an editor that starts counting at 0? One checkbox makes the numbering zero-based. And it numbers exactly the lines this tool counts, so the numbered output and the stat cards can never disagree with each other.

1. Type, paste, or drop a file into the box. Drag a .txt, .log, or .csv straight in, or hit Choose a text file to browse. It's all read on your own device, and the counts update on every keystroke, no button.
2. Read the top row of stats. Total, non-empty, and blank lines on the left, then longest, shortest, and average line length on the right, plus words and characters.
3. Check the longest-line number if you're chasing a width limit, then jump to that line in your editor.
4. Set the trailing-newline rule with the checkbox below the box if your text ends in a line break and the count looks off by one.
5. Turn on line numbering when you want the numbered text itself, tweak the separator and alignment, then Copy numbered or Download .txt.

Most counters give you one number, and it's usually the one that fails you first, because "lines" means different things depending on the job. Total lines is every line, content or not, the number an editor's status bar shows. Non-empty lines strips the blanks, and it's the count that matters when each line is supposed to be a real thing, a name, a data row, an email you're about to import. Twelve lines with two blank separators means ten actual entries. Blank lines is the difference, and it's the one that catches problems, an unexpected blank means a stray double-Enter or an empty row that'll break an import.

A blank line here isn't only a truly empty one. A line of nothing but spaces or tabs counts as blank too, because you can't see the difference and neither can your reader. Naive counters miss that and mark it as content. This one trims first, so a whitespace-only line lands in the blank count where it belongs.

Take x followed by a single newline. How many lines is that? You can defend either answer. One line, because the newline just ends the content, the way a proper text file's last line does, and wc -l reports 1. Or two, because splitting that string on the newline gives ["x", ""], which plenty of web tools count as two.

Neither is wrong, they answer different questions. This tool defaults to the "one line" reading, so a 100-row file that ends cleanly with a newline is 100 lines, not 101. That matches wc -l, most editors, and how people think about their data. The checkbox flips it to the naive split, which helps when you're debugging why your own code reports a different number and want to see its answer. That setting only affects the final break, and blank lines inside the text count either way.

Line breaks aren't one character. Unix and macOS use a single line feed, Windows uses a carriage return plus a line feed (two characters for one break), and old classic Mac used a lone carriage return that still turns up in exported files. A counter that only knows the Unix break miscounts Windows text and leaves a stray carriage return on every line, which throws off the non-empty check.

This tool normalizes all three before counting, so the same text gives the same number wherever it came from. Copy a list from Notepad, from a Mac terminal, or from a diff on GitHub, and the count holds. That's what simple counters get wrong the moment real pasted text shows up.