Free CODEOWNERS Tester
Paste a CODEOWNERS file and some paths to see who GitHub will ask to review each file, and which line decided it.
What is a CODEOWNERS Tester?
A CODEOWNERS file tells GitHub who must review changes to each part of a repository. This tester reads the file, checks a list of paths against it, and shows the owners of every path along with the line that decided them.
Matching follows GitHub’s documentation: gitignore-style patterns, the last matching line wins, a line without owners removes ownership, and paths are case-sensitive. It also applies GitHub’s documented exception that docs/* covers only files directly inside docs, and rejects the negation and bracket syntax GitHub doesn’t support.
Key Features
The Deciding Line for Every Path
Each path lists its owners with the line number and pattern that assigned them. When the wrong team is requested, you see which line did it.
Owners Grouped by Team
Switch to By owner to list every path each user, team or email covers. It answers which files a team will be asked to review.
Unowned Files Counted
Paths no rule matches, or that a line deliberately leaves without owners, are counted separately. Gaps in review coverage stand out.
Syntax GitHub Rejects, Caught Early
Negation, bracket ranges and malformed owners such as a team without @ are reported with their line number before you push.
Your Org Chart Stays Private
The file and paths are checked in the browser, so team names and internal paths aren’t uploaded.
Perfect for everyone
- Engineering leads assigning reviewers
- Platform teams running monorepos
- Developers puzzled by an unexpected review request
- Anyone editing a CODEOWNERS file
How to Use the CODEOWNERS Tester
Paste the file, list the paths, and read who owns each one.
Paste Your CODEOWNERS File
Copy it from .github/, the repository root or docs/, comments included. Comments and blank lines are skipped, and line numbers match your file.
List the Paths to Check
Add one path per line, relative to the repository root, such as apps/web/page.tsx. A pull request’s changed files are a good list to start with.
Choose By Path or By Owner
By path shows each file’s owners and the deciding line. By owner groups the same results under each user, team or email address.
Fix the Line and Recheck
Edit a rule and every path updates at once. When the owners look right, copy the file back into your repository.
CODEOWNERS Files Against Real Paths
Each example shows the CODEOWNERS lines, a line of three dashes, then the paths. The answer is the tester’s report in the mode on the chip, so work out the owners before revealing it.
“* @acme/engineering *.js @acme/frontend --- README.md src/index.js”
“/apps/ @acme/apps * @acme/everyone --- apps/web/page.tsx”
“* @all docs/* @acme/docs --- docs/setup.md docs/api/auth.md”
“apps/ @octocat /build/logs/ @doctocat --- src/apps/main.go build/logs/today.txt src/build/logs/old.txt”
“* @acme/engineering /pnpm-lock.yaml --- pnpm-lock.yaml README.md”
“* @acme/engineering *.md @acme/docs docs@example.com --- README.md src/app.ts CHANGELOG.md”
“docs/ @acme/docs --- docs/a.md Docs/b.md”
“!docs/ @acme/docs --- docs/a.md”
“*.js frontend-team --- app.js”
“*.[jt]s @acme/frontend --- app.js”
How GitHub Reads a CODEOWNERS File
The syntax looks like .gitignore, and mostly is. These ten rules include the places where it isn’t.
The Last Matching Line Wins
When several lines match a file, the one furthest down decides. Put the catch-all star rule at the top, not the bottom.
“The star rule is the last line. Who owns apps/web/page.tsx?”
No Leading Slash Means Any Depth
apps/ matches an apps folder anywhere, such as src/apps/. Write /apps/ to mean only the folder at the root.
“Does apps/ match src/apps/main.go?”
docs/* Covers Direct Children Only
GitHub documents that docs/* matches docs/setup.md but not docs/api/auth.md. It’s one place CODEOWNERS differs from .gitignore.
“Does docs/* match docs/api/auth.md?”
A Trailing Slash Covers Everything Inside
/docs/ matches every file under docs at any depth. It’s the usual way to give a team a whole folder.
“Does /docs/ match docs/api/auth.md?”
Extension Patterns Match Everywhere
*.js matches JavaScript files in every folder, because the pattern has no slash. Narrow it with a path, as in /src/**/*.js.
“Does *.js match src/lib/index.js?”
A Line Without Owners Removes Ownership
A pattern on its own, such as /pnpm-lock.yaml, leaves matching files with no code owner. Use it for generated files nobody needs to review.
“What does a line with only a pattern do?”
Owners Are Users, Teams or Emails
Write @username, @org/team-name, or an email address linked to a GitHub account. A team must be visible and have write access to the repository.
“Is frontend-team a valid owner?”
No Negation and No Ranges
CODEOWNERS supports neither exclamation-mark negation nor character ranges in square brackets, and GitHub skips lines that use them. Override with a later, more specific line instead.
“Can a CODEOWNERS line exclude files?”
Paths Are Case-Sensitive
GitHub matches CODEOWNERS patterns case-sensitively, so docs/ doesn’t cover Docs/. Use the folder name exactly as git stores it.
“Does docs/ match Docs/b.md?”
Escape a Leading # With a Backslash
A line starting with # is a comment, and a # after the owners starts a comment too. Write a backslash before the # to match a file whose name starts with one.
“How do you match a file named #notes.md?”
How GitHub Uses the File
The syntax is only half of it. Where the file lives and which branch it’s on decide whether it applies at all.
Three Possible Locations
GitHub looks for CODEOWNERS in .github/, then the repository root, then docs/, and uses the first one it finds. Keep only one copy to avoid confusion.
Automatic Review Requests
When a pull request changes a file, GitHub requests reviews from that file’s code owners. Draft pull requests wait until they’re marked ready.
Required Code Owner Approval
A branch protection rule or ruleset can require a code owner’s approval before merging. Then the deciding line sets who must approve each file.
The Base Branch’s Copy Counts
GitHub reads CODEOWNERS from the pull request’s base branch, so edits to the file apply only after they’re merged.
A 3 MB Size Limit
A CODEOWNERS file over 3 MB isn’t loaded, so nobody is assigned. Use wildcards and folders rather than listing every file.
GitLab and Bitbucket Differ
GitLab adds named sections and optional approvals, and Bitbucket uses its own add-on syntax. This tester follows GitHub’s rules only.
CODEOWNERS Mistakes to Avoid
Most wrong review requests come from rule order, folder patterns or permissions.
Putting the Catch-All Last
Ending the file with a star rule overrides every line above it, so that team owns everything. Move the catch-all to the top.
Expecting docs/* to Cover Subfolders
docs/* stops at files directly in docs. Use /docs/ to include every nested folder.
Owners Without Write Access
Users and teams without write permission are ignored as owners, so their lines quietly do nothing. Check repository permissions as well as syntax.
Misspelled Team Names
@acme/front-end and @acme/frontend are different teams, and an unknown team shows as an error in GitHub’s file view. Copy names from the team page.
Expecting Edits to Apply Immediately
New rules take effect only once CODEOWNERS is merged into the base branch. Open pull requests keep using the old file.
Copying .gitignore Negation
A negated line pasted from a .gitignore is invalid in CODEOWNERS. Replace it with a later, more specific rule.
Forgetting Generated Files
Lockfiles and generated code can pull a whole team into every review. Add a line with no owners for them.
Folder Case Drift
A folder renamed from Docs to docs on macOS may keep its old case in git. Check the path as git stores it before writing the rule.
Rules for Common Repository Layouts
Starting points you can adapt. Remember that a later line overrides an earlier one.
Monorepo Packages
Give each package folder its team with lines like /packages/billing/ @acme/billing, below the catch-all. Shared config such as /tsconfig.base.json can go to the platform team.
Front End and Back End by Extension
*.tsx @acme/frontend and *.go @acme/backend split reviews by language. Put them above folder rules when a folder’s owner should take precedence.
Infrastructure and CI
Route /.github/workflows/ and /infra/ to a platform or security team, since changes there affect every deploy.
Docs With Two Owners
List two owners on one line, such as /docs/ @acme/docs @acme/engineering. An approval from any listed owner satisfies the code owner requirement.
Sensitive Files
Assign /SECURITY.md, /.github/CODEOWNERS and authentication code to a security team, so changes to ownership itself need their review.
Generated and Vendored Code
Lines with no owners for /vendor/ and lockfiles keep large automated diffs from paging whole teams.
When to Test CODEOWNERS
Whenever a review request surprises someone, or before ownership changes land.
Explaining an Unexpected Review Request
Paste the file and the changed paths to see exactly which line pulled in a reviewer.
Planning a Folder Reorganisation
Before moving folders, test the new paths to check every file still lands with the right team.
Finding Unowned Files
List the repository’s files and look at the No owner count, so nothing slips through review.
Reviewing a CODEOWNERS Change
When a pull request edits CODEOWNERS, compare who owns key paths before and after the change.
Onboarding a New Team
By owner shows which files a team will be asked to review as soon as its line is merged.
Pruning Dead Rules
Test the full file list. A line number that never appears in the Line column decides nothing and can go.
Checking Monorepo Boundaries
Confirm each package folder maps to its owning team, and shared config stays with the platform team.