The GitHub Search Qualifier Reference: What Each Filter Matches and Misses

This reference is for in-house recruiters, sourcers, and founders who are about to type a GitHub search to find engineers. It has one row per qualifier and graph surface, and each row says which search type accepts it, what field it actually matches, what it proves about a candidate, and how it misleads. Find the row you need and check it. The procedure and the failure modes come after the tables.

Which GitHub search surface does each qualifier belong to?

Each GitHub qualifier works on specific search surfaces only, so choose the surface before you write any qualifiers. There are five surfaces: user, repository, code, commit, and issue/PR. They differ in whether you need to log in, how fast you can query them, and what part of GitHub they index.

Two terms used throughout:

• A qualifier is a key:value filter typed into the search bar, such as location:berlin or language:rust.
• A surface is the search type that runs the query. The same text in the bar returns different things on user search and on code search.

Some limits apply to every surface. Learn these before you trust any result count:

• Result cap. GitHub returns "up to 1,000 results for each search", in pages of up to 100. Anything past 1,000 is not returned.
• Query length. "Queries longer than 256 characters are not supported", and you cannot use more than five AND, OR, or NOT operators in one query.
• Timeouts. If a query times out, search "returns all matches that were found prior to the timeout". You get a partial list, and nothing on the page tells you it is partial.
• Repository scope. GitHub's REST search docs say the API "will find up to 4,000 repositories that match your filters".

Code search has two syntaxes. The new qualifiers path:, symbol:, and content: belong to the new code search syntax. GitHub says the legacy syntax is the one "you should only need to use for the REST API endpoint for searching code". In practice that means the new qualifiers work in the browser, and scripts that call the code endpoint have to use the legacy syntax. I am reading that from GitHub's wording. GitHub does not state it as a rule, so test it on your own query before you build a script around it.

This reference covers GitHub's own search. An X-ray search, meaning a site-restricted query in a web search engine, reads the same free-text profile fields. The location and empty-field warnings below therefore apply to it as well.

User search qualifiers: what language:, location:, and followers: actually match

User search qualifiers match fields on the account and on the repositories it owns. They do not look at the work a person has done. language: matches the majority language of the repos they own, location: matches whatever text they typed into their profile, and followers: measures audience size.

GitHub's documentation shows exactly how language: behaves. The example language:javascript location:russia "matches users in Russia with a majority of their repositories written in JavaScript." The filter counts only repos the person owns, so contributions to other people's repos do not count. Someone who spent five years committing Rust to an employer's org can fail language:rust if their personal account holds mostly dotfiles.

Two more user qualifiers are useful for sourcing:

• type:user or type:org limits results to people or to organizations. Use type:user on every people search. Otherwise company accounts take up slots that count toward the 1,000 cap.
• is:sponsorable finds accounts that can receive GitHub Sponsors. This shows they have set up Sponsors. It does not show that anyone pays them.

Many sourcing guides recommend follower thresholds. I have not found any evidence that a particular follower count separates good engineers from average ones, so I don't use followers: as a quality bar. I use it as a way to split a query that hits the cap, which is a job it does well.

The sources behind this reference do not document how GitHub assigns a language to a repository. To see what GitHub thinks a repo is written in, open the repo and read its language bar.

Missing profile data also hurts. Per-field fill rates for GitHub users have not been published. The nearest proxy is an academic snapshot of the top 10,000 repositories, which found that 33% were owned by accounts with an empty location field. Any location: filter will miss those people, however you spell the city.

language: measures what someone owns, not what they ship.

Code, commit, and issue/PR qualifiers: what they match and where they go blind

These surfaces search people's work, not their profiles. A hit is stronger evidence than a profile match, but each surface covers less. Code and commit search see only the default branch, and code search requires a login and skips most forks.

What each one proves about a candidate

• A code hit shows the code exists on the default branch of an indexed repo. It does not show who wrote it. Check the file history before you credit anyone.
• A commit on the default branch found with repo: plus author-email: shows that person's work made it into the project's main line. Of everything on GitHub, this is the closest thing to evidence of shipped work.
• reviewed-by: on pull requests suggests the project trusts the person to judge other people's code. My reading is that this is a stronger seniority signal than any follower count. Confirm it against the PRs themselves.
• commenter: and involves: show participation, which can be a single drive-by comment. Use them to widen a list, not to qualify people.

Commit search by author email

To check a specific person against a specific repo, search commits by author email: repo: plus author-email: with the full address. It fails in three cases: you only have part of the address, the person commits from a noreply address, or the work never reached the default branch. For scripted runs, the GitHub CLI has gh search commits, which hits the same commit search and has the same limits.

Graph surfaces: contributors, stargazers, forks, and dependents

Graph surfaces list the people attached to a specific repository. That makes them the closest GitHub gets to "who actually worked on this". Each list has either a ceiling or a bias, though, and it hides part of the population you are looking for.

Contributors: the 500-email ceiling

GitHub documents that the contributors endpoint links "only the first 500 author email addresses in the repository" to user accounts. Beyond that, contributors come back as anonymous, and many tools drop those rows without telling you. That means large repos lose exactly the people a sourcer wants most: long-tail contributors who have done real work and who recruiters watching the top of the list rarely contact. The data can also be a few hours old, which matters only if you are watching a fast-moving repo for new names.

Dependents and "Used by": no longer a usage measure

The "Used by" count, and the dependents list behind it, come from the dependency graph. GitHub first let owners disable the graph on public repos. It then made the graph default to off for new public repos and started removing data for inactive repos. GitHub defines "inactive" as no commits in over three years, no Dependabot, and not referenced by any published package.

As one maintainer put it: "The dependents metric has been very useful as a popularity measure for Github repos, but with the change its probably not usable for that anymore." A low count on a new repo now tells you more about the owner's settings than about how many people use it. GitHub's own docs are inconsistent here, and some pages still say the graph is "on by default". I have not verified an official dependents API, so treat any tool that claims to pull dependents in bulk with suspicion until you have tested it.

The pivot work, and where it gets heavy

Running contributor, commit, and profile pulls across several target repos, then deduplicating and checking each person, is where most of the hours go. Refolk handles that join. You describe the people you want in plain English, and the repo evidence and profile come back together for each person.

How big is the market behind your query?

Size the market before you search, because the size predicts whether a user query will hit the 1,000 cap. In Refolk's index of professional profiles, Go in Germany is 4.9 times the size of Rust in Germany, so the same query shape behaves very differently in the two markets.

How to use these figures:

• Large markets need splitting first. Five thousand people with Go in Germany will not fit in one query capped at 1,000. Plan the slices before you start.
• Small markets need wider location strings. With 1,059 Rust profiles across all of Germany, a query for one city spelled one way will come back thin. Run the country, city, and metro variants.
• Title mix varies a lot by market. In the 25-person samples, founder or CTO-type titles appeared on 44% of German Rust profiles and 20% of US Rust profiles. Each sample is only 25 people and is not representative. Take it as a reason to check titles, not as a rate to plan around.
• Employers give you repo pivots. The most common employers in the German Rust sample included Typst, Hex-Rays, and Geo Engine. Any public org belonging to companies like these becomes a repo: or contributors anchor for the graph pivots above.

Rust in the United States (3,708) is 3.5 times Rust in Germany. A US Rust query split by metro behaves more like the German Go market than the German Rust one.

How to search GitHub for engineers without trusting a truncated list

Choose the surface first, sign in, keep the query within the length limits, split anything that reaches 1,000, pivot to the graph surfaces, and then verify every person by hand. Each step below has a time budget and a test for when it is done.

Not everyone orders the steps this way. A widely read recruiter guide starts from user search with type:user and adds qualifiers from there. I put choosing the surface first because which qualifiers you can use depends on the surface. A commit-email check or a code path: query written into user search fails without any error message.

On the length limit: developers have reported the 256-character error appearing at 208 characters. Assume you have less room than the documentation says, and move long OR-lists of cities into separate queries.

Splitting a capped query

The API reports a total count but serves at most 10 pages of 100. As one practitioner tool puts it: "If 1,000 results are returned and the last page is full, there may be additional results that are silently truncated." GitHub does not publish a splitting method. The approach that works is to cut the query on one dimension at a time.

type:user language:go location:berlin followers:0..10
type:user language:go location:berlin followers:11..50
type:user language:go location:berlin followers:>50
type:user language:go location:germany followers:0..10
type:user language:go location:germany followers:11..50
type:user language:go location:germany followers:>50

GET /repos/OWNER/NAME/contributors?anon=1
repo:OWNER/NAME author-email:full.address@example.com
repo:OWNER/NAME author-date:>YYYY-MM-DD

How GitHub search misleads sourcers: failure modes and false positives

GitHub search usually goes wrong silently. You get a list that looks complete but has dropped people because of a cap, a branch limit, a blank field, or a spelling variant, and it includes people who match a proxy without doing the work. Each failure below lists the false positive, the false negative, and the check that catches it.

language: on user search

• False positive: someone who owns many forked or tutorial repos in the language.
• False negative: a Rust engineer whose own repos are mostly dotfiles or config, with the real work in an employer's org.
• Check: open the pinned repos and read the language bar.

location: free text

location: matches whatever the person typed. "Germany", "Berlin", and "Berlin Metropolitan Area" are different strings and return different people. In Refolk's 25-person samples, the strings split like this:

In the German Go sample, 15 people were in Berlin, but they used two different Berlin strings (11 and 4). A single location:berlin spelling would miss part of the city, and a city query misses the 8% who wrote only the country.

• False positive: rare, though a stale location string will place someone where they no longer live.
• False negative: every metro or country-only variant, plus the roughly one third of top-repo owners who leave the field blank.
• Check: run city, metro, and country variants as separate queries. Asking Refolk for "Go backend engineers in Berlin" saves writing the variant set by hand, though you should still read the location on each profile you shortlist.

The 1,000-result cap

• False positive: none. The problem is false confidence.
• False negative: everyone past result 1,000, dropped without any notice.
• Check: if the last page is full at the cap, split the query.

Code search

• False positive: a code hit credited to the repo owner when someone else wrote the file.
• False negative: work that lives in forks, feature branches, files over 384 KB, or repos with 500,000 or more files.
• Check: look at the upstream repo's commits by author.

Contributors list

• False positive: none in particular. The list undercounts rather than overcounts.
• False negative: contributors beyond the 500-email linking cap, which many tools drop.
• Check: pass anon=1, or switch to commit search on repo:.

Dependents and "Used by"

• False positive: an older, active repo can look more important than a newer one that is used just as widely.
• False negative: repos created after the default-off change, and inactive repos whose data was removed, show low counts whatever their real usage.
• Check: none that rescues the metric. Don't use it as a popularity filter.

author-email: and commit search

• False positive: rare, since the match is exact.
• False negative: partial addresses, noreply addresses, and work merged anywhere except the default branch.
• Check: get the exact address from a commit the person authored on the same repo, then search with that.

Timeouts and query length

• Timeouts return whatever matched before the timeout, and the page looks like a normal result. If a total seems low for the market size, re-run the query in narrower slices.
• Query length errors have been reported well under the 256-character limit. Break long OR-lists into separate queries instead of trimming them.

Keeping this reference current

GitHub changes limits and defaults in its documentation and changelog, and the search results themselves never show the change. Re-check the mechanisms behind each row rather than copying the numbers forward. These are the places to look:

• GitHub Search docs for qualifier syntax on each surface and for code index exclusions such as the 384 KB file limit and the fork rule.
• The GitHub REST search reference for the 1,000-result cap, the page size, and the per-minute rate limits.
• The dependency graph changelog for whether the graph still defaults to off and how GitHub defines "inactive".

Three things in this reference are not established, and you can check each one yourself:

• Commit search and login. Run a commit search in a signed-out browser and see whether it returns results.
• Stargazer and fork pagination. Page through the stargazers of a repo with a known star count and see where the list stops.
• False-negative rate of code search. Nobody has published one. Pick five engineers whose work you know, search for their code, and count the misses.

Before your next search, find the market's size in the stat table above. If it is in the thousands, plan the slices before you type the first qualifier.