How do you export a GitHub stargazers list to CSV?

Open any repo’s stargazers page (github.com/owner/repo/stargazers) and you get a wall of avatars with pagination. No download link, no CSV, no filters. There is no stars-over-time chart either: the star history graphs you see in project READMEs come from third-party sites built on the same API you are about to use. Stars were built as a bookmark feature for readers, not an analytics feature for maintainers, and GitHub’s UI reflects that: the count is a number on the repo page and the list is something you scroll.

The good news is that the list is public data with an official, documented API behind it. Anyone can see who starred a public repo, and GitHub’s REST API will return the same list in a machine-readable form, within its published rate limits. So every “export stargazers” answer ends up in the same place: a small script against the API. Here is a complete one.

You need two tools: the GitHub CLI (gh) and jq. Both install from any package manager. Run gh auth login once so your requests are authenticated, then save this script and point it at a repo:

#!/usr/bin/env bash
# Export a repo's stargazers to CSV: login, star date, profile URL.
# Needs the GitHub CLI (gh) and jq. Run "gh auth login" once first.
# Usage: ./export-stargazers.sh owner/repo > stargazers.csv
set -euo pipefail

REPO="$1"

echo "login,starred_at,profile_url"
gh api "repos/$REPO/stargazers?per_page=100" \
  --paginate \
  -H "Accept: application/vnd.github.star+json" \
  --jq '.[] | [.user.login, .starred_at, .user.html_url] | @csv'

Three details make this work. First, --paginate follows the pagination links automatically, so one command walks every page at 100 stargazers each. Second, the Accept: application/vnd.github.star+json header changes the response shape: without it the endpoint returns bare user objects and drops the star date entirely. With it, each item includes starred_at, which is the column that makes the export useful for anything time-based. Third, jq’s @csv filter handles quoting for you, so odd characters in a login can’t break the file. The output looks like this:

login,starred_at,profile_url
"tobin-dev","2026-06-30T14:12:09Z","https://github.com/tobin-dev"
"nadia-builds","2026-06-29T08:41:55Z","https://github.com/nadia-builds"

If you prefer raw curl over the CLI, the same endpoint works with a personal access token and a loop over the page parameter, but you will be re-implementing what --paginate already does. The CLI version is the one to keep.

Authenticated requests get 5,000 per hour. Unauthenticated requests get 60, which is why logging in first is not optional for anything beyond a toy repo. At 100 stargazers per request, the arithmetic is friendly: a 10,000-star repo is 100 requests and finishes in under a minute. Even a 40,000-star repo is only 400 requests, a small fraction of one hour’s budget. The export itself is rarely where the rate limit bites.

There are two harder limits worth knowing before you point this at a huge repo. First, GitHub caps pagination on the stargazers list itself: after roughly 400 pages, about 40,000 stargazers, the REST endpoint stops serving further pages. Past that point you need the GraphQL API with cursor-based pagination, which is a meaningfully bigger script to write and babysit. Second, the budget problem moves the moment you go beyond the list. The stargazers endpoint costs one request per 100 people, but fetching each person’s full user record costs one request per person. Enriching 20,000 stargazers that way is four hours of your entire hourly limit, assuming the token does nothing else in the meantime.

Three useful columns: the login, the star date, and the profile URL. That is genuinely it. The user objects this endpoint returns are stubs. There is no display name, no company, no location, no role, and no email field at all. Even the full per-user endpoint only shows an email when the developer chose to publish one, which most have not.

For some jobs the raw file is enough. Counting stars by week, spotting a launch spike, or checking whether a competitor’s repo is accelerating all work fine on logins and dates. But if the reason you wanted the export was outreach, recruiting, or user research, a list of handles is not a list of people. You still need to answer, for each row: who is this, where do they work, what do they do, and is there a public way to reach them? Our guide on finding a stargazer’s email covers where a public email can come from and why most stay hidden.

The manual route: for each login in your file, fetch the user record (gh api users/LOGIN) or open the profile in a browser, then copy over the name, company, and location, plus a public email where one exists. A row like nadia-builds might become “Nadia Osei, platform engineer at a fintech, nadia@example.com”. At a minute or two per person, a 1,000-star repo is a full working week of copy-paste, and a scripted version has to handle retries, rate-limit pauses, and the 5,000-per-hour ceiling on per-user requests. It is doable. It is also exactly the kind of grind a tool should absorb.

WarmStars is that tool: paste a public repo URL and it scans every stargazer into a named profile, with company, role, location, star date, and a public email where the developer published one. Every email carries a confidence tier (verified, high, medium, or likely), it uses public data only, and it honors a do-not-contact list. One click exports the whole enriched table as CSV. To be straight about pricing: emails and CSV export are paid features, on plans from $39 a month (see pricing). The free plan gives you two scans a month on repos up to 5,000 stars, with each stargazer’s name, company, and location in the app, so you can judge the data quality before paying for the file.

If the export is feeding a sales motion, the dev tool sales page shows how teams use the enriched list day to day.

Exporting is fine: the list is public, the API is official, and staying inside the documented rate limits is the whole ask. The responsibility starts with what you do next. If the list becomes outreach, honor opt-outs, follow the email laws where your recipients live, and write to people about the thing they actually starred rather than blasting the whole file. A star is opt-in interest, which is what makes this list better than a bought one, and careless sending is the fastest way to waste that. Our guide on turning stars into customers walks through doing it well.