Bytes tell you weight. This tells you volume.

The question size alone can't answer

"How big is this repository" is really two different questions wearing one trench coat. There's disk weight — how many megabytes you'll pull down — and there's code volume — how much actual logic you're signing up to read, review, or maintain. A repository full of pre-rendered documentation images or a checked-in vendor/ directory can be enormous in bytes while containing very little written code. Conversely, a lean, dependency-free utility library can weigh almost nothing while still representing thousands of carefully written lines.

RepoKit's lines-of-code estimate exists specifically to separate those two signals. It runs as a companion figure to the byte-size badge, appearing on the same rows, so a quick scan of a repo's root listing tells you not just "this folder is 12 MB" but "this folder is 12 MB across roughly 8,400 lines" — two numbers that, read together, say something neither says alone.

How the estimate is produced

RepoKit reads file contents through GitHub's API and counts newlines efficiently across the tree, layering the result in as a second pass after the initial size annotation (which only needs lightweight tree metadata and therefore appears first). Binary and non-text files — images, fonts, compiled bundles, lockfile blobs — are correctly excluded from the count rather than reported with a misleading line number, since a "line count" for a PNG isn't a meaningful concept.

The result is a genuinely useful estimate, not a precision code-metrics tool. It's the same category of signal as running wc -l across a checkout — a fast, honest approximation of scale, not a claim about code quality, complexity, or test coverage.

Where this becomes genuinely useful

• Evaluating a new dependency — before adding a package to your project, a quick LoC glance tells you whether you're pulling in a focused 600-line utility or a sprawling 80,000-line framework, which changes how much due diligence is worth doing.
• Sizing up an unfamiliar codebase — when you're about to contribute to or review a repo you've never opened before, LoC-per-folder gives you a mental map of where the "real" code lives versus where the scaffolding, docs, or generated assets sit.
• Spotting generated or vendored code — a folder with an outsized byte count but a suspiciously low or nonsensical line count is often a sign of binary assets or minified bundles rather than hand-written source.

Frequently asked questions