Before you adopt a library, review a PR-heavy monorepo, or just decide whether a repo is worth your time, you usually want one simple answer first: what's actually in here? How big is it, really — and how much of that is code versus docs, configs, and everything else?
The default way to find out is to clone it. For a lot of enterprise and open-source repos, that's a bad first move: a multi-gigabyte checkout, a node_modules install, disk space you didn't want to spend, all to answer a question that shouldn't need any of it.
The problem with "just clone it"
I kept hitting this while evaluating other people's repos — including while building AI Interview SDK, where I was constantly sizing up other monorepos for comparison. Cloning answers the question eventually, but it's slow, it's heavy, and it's local-setup-per-repo: a new clone, a fresh look, then you probably delete it.
Repository File Count is my answer: paste a repo, get the breakdown, no clone.
No cloning — just the GitHub API
The whole tool is one idea taken seriously: GitHub already exposes a repo's entire file tree over its REST API (GET /repos/{owner}/{repo}/git/trees/{sha}?recursive=1). There's no need to pull the actual file contents down to count and classify files — the tree alone has everything: every path, extension, and blob size in a single response.
Paste: github.com/owner/repo
→ fetch the default branch SHA
→ walk the recursive git tree (one API call)
→ classify every entry by extension
→ total files · code files · non-code files · per-extension breakdown
You sign in with a GitHub personal access token (read-only is enough), and that token never leaves your browser — it talks to GitHub's API directly from your device. Nothing is sent to a server, nothing is stored. The tool doesn't have a backend to store it in.
Code vs. everything else
Raw file count is a weak signal on its own — a repo with 3,000 files could be 200 source files and 2,800 generated assets. The tool separates real code from docs, configs, and assets, then breaks the code down by extension, so "how big is this, really" gets an honest answer instead of a single misleading number. Config files (json, yaml, yml, toml, xml) are toggleable — sometimes you want them counted as code, sometimes you don't — and the toggle re-filters instantly against data already fetched, no extra API calls.
Honest about its own limits
Very large repos can hit GitHub's tree-truncation limit, where the API silently stops returning entries past a certain size. Instead of quietly under-counting, the tool flags truncation explicitly — the count you get stays honest about what was actually measured, rather than implying completeness it doesn't have.
Built to answer one question fast
Sign in, paste a URL, get a breakdown you can copy as Markdown straight into a PR description or your notes. There's also a usage view for your GitHub API rate limit, read from your own recent activity so checking it never costs you a request.
It's a small tool next to a multi-package SDK, but it scratches a real itch: understanding a codebase should be faster than downloading it.