Line Counter

This line counter breaks any pasted text or source code into total lines, blank lines, comment lines, and real code lines, along with maximum and average line length. It is useful for developers sizing up a file, writers checking document structure, and anyone who needs more detail than a simple word count provides. Everything updates as you type and stays on your machine.

How Each Metric Is Computed

Metric	Definition
Total lines	Lines after normalizing endings and removing one trailing newline
Non-empty lines	Lines with at least one character after trimming (when trimming is on)
Blank lines	Total lines minus non-empty lines
Comment lines	Lines whose first non-space characters match a comment marker
Code lines	Non-empty lines minus comment lines
Max / average line length	Computed over non-empty lines, after trimming if enabled

Because code, comment, and blank lines are derived from the same non-empty count, they always sum back to the total — there is no double counting.

Worked Example: A Short Python File

Paste this nine-line snippet with trimming and comment detection both on:

import math

# circle area
def area(r):
    return math.pi * r * r

# --- test ---
if __name__ == "__main__":
    print(area(2))

The statistics table reports:

• Total lines: 9
• Non-empty: 7 (the blank lines 2 and 6 are excluded)
• Blank: 2
• Comment: 2 (# circle area and # --- test ---)
• Code: 5
• Max line length: 26 (if __name__ == "__main__":)
• Average line length: 16.0

If you enable Trim whitespace, the indented return line is measured without its four leading spaces, which is why the average lands at 16.0 rather than higher.

Comment Detection Rules and What They Miss

This is intentionally a fast line-prefix heuristic, not a parser. That makes it useful across languages without configuration, but it has known blind spots:

• Only the line start is checked. x = 1; // set x is code, and so is a /* ... */ block whose opening brace sits mid-line.
• C preprocessor directives misfire. #include <stdio.h> starts with # and is counted as a comment even though it is code.
• Pointer maths misfires. A C line starting with *ptr = 5; matches the * comment rule and is counted as a comment while */-style closers are not.
• Shell flags can misfire. A line beginning with --verbose is counted as a comment because -- is the SQL/Lua marker.
• Block comments are not tracked across lines. Only the marker-bearing lines are counted; a multi-line block contributes as many comment lines as it has marker lines, not as many as it spans.

Use the count as a signal, not an audit. A static examiner will always be more precise for a specific language.

Line Endings and the Trailing-Newline Edge Case

Files from Windows arrive with CRLF endings, files from classic Macs with bare CR, and Unix tools with LF. The counter normalizes all three to LF first, so line counts match across sources. It then removes exactly one trailing newline: "a\nb\n" counts as 2 lines, not 3, while "a\nb\n\n" counts as 3 with one blank line. Empty input returns all zeros rather than an error. If you disable trimming, a line of pure spaces is no longer blank and is included in the length statistics with its padding intact.

What Line Counts Tell You — and Don’t

Lines of code is one of the oldest software metrics and one of the most misused. Raw totals describe size, not quality: a terse, elegant function and a bloated one can do the same job in very different counts, and using LOC to rank developer productivity famously rewards verbosity while punishing the refactoring that removes lines.

Where the breakdown earns its place is in characterising a codebase. A high comment ratio usually signals well-documented code — or stale comments. A long maximum line often flags formatting debt. An unexpected jump in the blank-line percentage can betray generated or machine-merged output. For prose and data, the same numbers answer practical questions: does this log have empty rows, is my dataset one record per line, how consistent are my line lengths? This tool gives you those signals instantly, without setting up a static-analysis suite.

Practical Tips

• Compare a file before and after a refactor. Paste the old version, note code and comment lines, then paste the new one. Fewer code lines with the same comment count usually means a real simplification; a drop in comment lines is a warning, not a win.
• Enforce a column limit. If your project caps lines at 80 or 100 characters, the maximum line length shows immediately whether anything breaks the rule, and the average tells you how much headroom the rest of the file has.
• Audit data and logs by blank percentage. A well-formed CSV should contain zero blank lines, while a log exported in chunks often grows blank separators. An unexpected blank percentage catches a malformed export before it reaches a database.
• Never compare languages or people by code lines. Python expresses in ten lines what Java may take thirty to write. Use the count to track one file or project over time, not to rank languages or developers.

Related Tools

• Word Counter — Count words, characters, sentences, and reading time.
• Text Statistics — Get a broader breakdown of pasted text.
• Diff Checker — Compare two versions line by line.