Pull request size calculator
Paste your git diff --stat output, get a size grade, an estimated careful-review time, and split suggestions based on code review research. Free, runs entirely in your browser.
Everything stays in your browser. Tip: run git diff --stat origin/main...HEAD on your branch before opening the PR.
Paste your diff stat to get a size grade, an estimated review time based on a ~400 reviewable lines/hour pace, and split suggestions.
What is the ideal pull request size?
Under 400 changed lines, with 200 as the comfortable target. The often-cited SmartBear study of code review at Cisco found defect detection drops sharply once a review session passes about 400 lines of code, and Google's internal research puts their median change at roughly 24 lines, with small changes reviewed in hours instead of days.
Size hits every stage of the review pipeline:
| Lines changed | Pickup behavior | Review quality | Rounds to merge |
|---|---|---|---|
| Under 100 | Same hour, between tasks | Line-by-line | 1 |
| 100-400 | Scheduled into the day | Thorough with effort | 1-2 |
| 400-1,000 | Procrastinated 1-2 days | Skimmed | 2-3 |
| Over 1,000 | Avoided | Rubber stamp | Many |
How is review time estimated?
This calculator assumes a careful reading pace of about 400 reviewable lines per hour plus a small per-file context-switching cost. That matches the range industry studies report for reviews that actually catch defects (300-500 LOC/hour). Skimming is faster; skimming is also how bugs merge.
The estimate is for the human pass. The mechanical pass (injection patterns, N+1 queries, missing error handling, convention drift) should not consume human minutes at all: an AI reviewer like Diffwise runs 40+ specialist agents on the diff within minutes of the PR opening, so the human estimate above gets spent on design and correctness instead of pattern-hunting.
How do I make my PRs smaller?
Stack them. Split a feature into a chain of dependent PRs (schema → data layer → API → UI), each targeting the branch below. Reviewers get four 150-line reviews instead of one 600-line review, and you keep shipping while earlier parts are in review. Tools like Graphite, git-machete, or ghstack automate the rebasing. Full tactics: How to Reduce Pull Request Review Time.
Frequently asked questions
How long should a code review take?
For a well-sized PR under 400 changed lines, 15-30 minutes of focused reading. If reviews routinely take an hour or more, the problem is PR size, not reviewer speed.
What is a good PR size?
Under 400 changed lines, ideally around 200. Past 400, research shows defect detection drops sharply and reviewers start skimming.
Do test files count toward PR size?
They count toward review time but at a lower cost per line, since tests are usually more mechanical to read. If tests push a cohesive change slightly past the limit, that's a fine exception.
How accurate is the review time estimate?
It's a planning estimate based on a ~400 lines/hour careful-review pace plus per-file overhead. Dense logic reviews slower; generated code and lockfiles review faster and arguably should be excluded from the diff stat entirely.
Is this calculator free?
Yes. Free, no signup, fully client-side. Your diff stat never leaves your browser.