Photo by Radowan Nakif Rehan on Unsplash
The anuraghazra/github-readme-stats repository has 79,700 GitHub stars — more than most major JavaScript frameworks. A single, free, open-source SVG widget generator, starred nearly 80,000 times by developers who all want the same thing: a GitHub profile that shows real data.
The demand for credible developer profiles is universal. But "GitHub README stats" is a category, not a product, and the category has hard ceilings. Understanding exactly what these widgets measure — and where they stop — tells you whether your profile is working as hard as you are.
Updated June 2026.
What GitHub README Stats Actually Show#
GitHub README stats is a family of open-source widgets that embed dynamic SVG image cards in your GitHub profile README. The most widely used, anuraghazra/github-readme-stats, works by returning an SVG from a hosted Vercel endpoint: paste one URL into your README markdown file, and GitHub renders an auto-updating card showing your public activity data. No API keys. No configuration beyond URL parameters. Zero ongoing maintenance.
The core stats card shows six metrics from your public GitHub activity:
Total commits — all commits pushed to your public repositories
Total pull requests — PRs you've opened across public repos
Total issues — issues opened across public repos
Contributed-to repos — public repos where at least one of your PRs was merged
Stars — total stars earned across public repos you own
Top languages — measured by bytes of code, not by frequency or proficiency
The top languages metric causes the most confusion. It counts bytes of code across all your public repos — not what you use most, not what you'd put on a resume. One large legacy PHP repo from 2019 will dominate your card over the TypeScript codebase you're shipping every day. According to GitHub's Octoverse 2025, TypeScript surpassed Python as the most-used language on GitHub for the first time ever in August 2025, driven by 66% year-over-year growth in TypeScript contributors. Yet plenty of developers' language cards still show older languages, because their larger public repos skew the byte count.
For a deeper look at what else to include in your profile README beyond widgets, see our complete GitHub profile README guide for 2026.
The Full GitHub Profile Stats Widget Ecosystem#
anuraghazra/github-readme-stats has 79,700 stars — and it spawned a category. Four tools now cover most of what developers add to their profile README:
anuraghazra/github-readme-stats (79.7k stars) — The original. Renders the main stats card, a top-languages card, and per-repo cards, all configurable via URL parameters. Twenty-plus themes. Free, hosted on Vercel. The gap between this tool and the rest of the ecosystem — 79,700 stars vs. 6,600–6,900 for competitors — reflects market reality: most developers use this one and stop.
DenverCoder1/github-readme-streak-stats (6.9k stars) — Shows your current contribution streak, longest streak ever, and total contributions this year. The most hiring-relevant widget in the ecosystem because it demonstrates consistency over time, not just accumulated activity.
ryo-ma/github-profile-trophy (6.6k stars) — Visual achievement trophies for GitHub milestones: follower counts, star totals, commit thresholds. Decorative rather than informational. Common on early-career profiles; less common on experienced engineers' pages.
antonkomarev/github-profile-views-counter (4.9k stars) — Tracks how many times your profile page has been viewed. A vanity metric — it can't distinguish recruiters from bots, and most visitors won't find the number meaningful.
Together, these four tools cover everything GitHub's public API can surface about a developer. Their aggregate adoption tells you something important: developers everywhere want their profile to show more than GitHub shows by default. The question is whether these widgets are enough — or just the starting point.
How to Add GitHub README Stats to Your Profile#
Three steps, under ten minutes:
Step 1 — Create the special repository. Go to GitHub and create a public repository named exactly the same as your GitHub username. If your username is janedev, the repo becomes github.com/janedev/janedev. GitHub auto-detects this naming convention and renders the README.md at the top of your public profile page.
Step 2 — Add your widgets to README.md. A clean, minimal setup that stacks three cards:
## Stats
Replace YOUR_USERNAME with your actual GitHub username. The hide_border=true parameter gives a cleaner look when stacking multiple cards vertically.
Step 3 — Commit and push. GitHub renders the README immediately. Widget images are fetched from external Vercel deployments on a rolling cache — typically 30 minutes to a few hours. First load may be slower if the Vercel instance is cold-starting.
For horizontal alignment on desktop, use inline HTML inside your README:
<p align="center">
<img src="https://github-readme-stats.vercel.app/api?username=YOUR_USERNAME&show_icons=true&theme=dark" />
<img src="https://github-readme-stats.vercel.app/api/top-langs/?username=YOUR_USERNAME&layout=compact&theme=dark" />
</p>Note: align attributes don't render consistently across all GitHub markdown views and break on mobile.
Five Limits No README Stats Widget Can Fix#
The widget ecosystem runs on GitHub's public API. That's both its strength — easy, free, auto-updating — and its hard ceiling. Here are the five walls every developer hits eventually.
1. Private repos are invisible — and that's where most real work lives#
GitHub Octoverse 2025 reported nearly 1 billion commits pushed in 2025, with 36 million new developers joining GitHub in that year alone. But the vast majority of professional developer commits happen in private repositories: employer codebases, client work, products in stealth. The anuraghazra maintainers are clear: the widget reads only GitHub's public API.
The result is a profile that can significantly undercount real output. A developer who's been shipping production code for three years in a private repo may show fewer public commits than someone who pushes to hobby projects on weekends. JetBrains' State of Developer Ecosystem 2025, which surveyed 24,534 developers across 194 countries, found that 66% of developers don't believe current code metrics accurately reflect their real contributions. The private-repo visibility problem is a large part of why.
2. Revenue, users, and product impact don't exist in GitHub's data model#
GitHub stores code. It doesn't store outcomes. A developer who shipped a product generating $8,000/month MRR — with 340 paying customers and a 4.8-star rating — has the exact same stats card as someone with twelve abandoned side projects. Both might have 800 commits and 200 stars. The widget can't tell them apart.
"GitHub gives recruiters something better than claims — repository choices, pull request comments, issue threads, release notes, and documentation habits show how a developer works with other people, how they maintain code, and what they choose to ship in public," noted one analysis of GitHub's role in technical hiring. But it still can't show whether the code produced results. Revenue, subscribers, and user counts are external to GitHub's data model entirely — no widget, URL parameter, or API scope can surface them.
3. SVG images are invisible to search engines and AI#
Every README stats widget delivers an SVG image hosted on an external server. When Google, Bing, or an AI citation engine crawls your GitHub profile, it sees an <img> tag. The commit counts, language breakdowns, and streak data inside that SVG don't exist as indexable text — they're pixels.
If you want your developer profile discoverable in search results or cited in AI-driven answers, this matters in 2026. AI search overviews pull from text content on crawlable pages. An SVG showing your commit count contributes nothing to that. For developers building a long-term discoverable online presence, the SVG architecture is a structural dead end. Our post on llms.txt and AI-discoverable developer profiles covers this in detail.
4. The public instance has documented reliability issues#
anuraghazra/github-readme-stats is an open-source project maintained by volunteers. The free public instance runs on Vercel and is subject to GitHub's API rate limits — 5,000 requests per hour. On a heavily-visited profile, or during traffic spikes, those limits get exhausted. Instead of your stats card, visitors see a "Max retries exceeded, cannot refresh" error image displayed in your README.
The project's GitHub issue tracker documented extended outages in late 2025 (issues #4679, #4658 among others). The maintainers' own recommendation for production-grade use: self-host the project on your own Vercel account, or use a GitHub Actions workflow that generates static stat images on a schedule and commits them to your repo. Both approaches are viable — but they're maintenance overhead that the standard ten-minute tutorials don't surface upfront.
There's also an API data boundary worth knowing: the widget only reads your first 100 repositories. If you have more than 100 public repos, older ones fall outside the stats calculation entirely.
5. There's no path from a stats card to a resume#
Nothing in the README stats ecosystem generates an ATS-ready resume. The data you're displaying on your GitHub profile — commits, projects, languages — exists there and nowhere else in a structured, exportable format.
Most developers update their resume less than once a year, while their GitHub activity updates every day. That gap means the freshest, most credible data about your work is locked inside a stats widget that can't be submitted to an ATS, shared as a PDF, or attached to an application. Your profile works for passive browsing. For active job applications, you're still opening a Word document and manually retyping.
What a Live Developer Profile Shows Instead#
The README stats ecosystem emerged because GitHub profiles needed more data. The right answer to "GitHub profiles need more data" isn't a better widget — it's a profile layer built specifically for how developers work.
A purpose-built developer profile handles the structural gaps the widget can't. For the private-repo gap: you add projects and work experience that aren't publicly visible on GitHub — proof by declaration rather than extraction, but structured, shareable, and on a real web page. For the revenue gap: connect a payment integration and each project card shows verified MRR or subscriber counts from Stripe, Dodo Payments, Lemon Squeezy, or Polar alongside the GitHub data. For the search-engine gap: the profile is a real, crawlable web page with text content — not a collection of SVG images embedded in a markdown file.
DevBio's GitHub stats component shows commits, stars, repos, top languages, and a 12-week contribution bar chart. It also includes a live contribution heatmap that matches GitHub's layout pixel-for-pixel, per-project commit sparklines for the last 52 weeks, and a skills component displaying up to 80 skills in responsive colored badges. Everything renders as native components at devbio.me/yourname — a real, indexable web page, not an image-laden README.
The same data that populates your public profile compiles into an ATS-ready LaTeX PDF at devbio.me/yourname/resume. A recruiter who finds your profile link can grab your resume in one click, on the same page, without you sending a separate file.
"GitHub doesn't reward posting: it rewards shipping. No consistent code, no audience. For technical creators willing to do that work, the platform compounds for years," noted one analysis of GitHub as a developer credibility platform. A live developer profile extends that compounding — not just code activity, but verified output and measurable impact in the same place.
For the full breakdown of which profile components carry the most weight with hiring managers and clients, see what to put on a developer bio.
GitHub README Stats vs a Live Profile: Head-to-Head#
Feature | README Stats Widgets | GitHub Native Profile | DevBio Profile |
|---|---|---|---|
Public commit count | Yes | Yes (partial) | Yes |
Private repo activity | No | No | No |
Top programming languages | Yes | No | Yes |
Contribution streak | Yes (streak-stats) | Heatmap only | Yes (heatmap + streak) |
Revenue / MRR display | No | No | Yes — 4 payment integrations |
Per-project commit sparkline | No | No | Yes (52-week per project) |
Indexable by Google / AI | No — SVG image | Partial — bio text only | Yes — full page text |
Custom domain | No | No | Yes |
ATS-ready resume | No | No | Yes (LaTeX PDF) |
Uptime / reliability | Varies (rate limits) | High | High |
Skills / tech stack component | No | No | Yes (up to 80 skills) |
One-link shareable profile | No | Partial | Yes |
The Proof Stack: What Strong Developer Profiles Show in 2026#
Static stats widgets answer one question: "how active is this developer on GitHub?" Recruiters, clients, and potential co-founders ask more than that. Here's the complete checklist — organized as the Proof Stack:
Layer 1 — Activity proof (what README stats covers)
[ ] Commit count and contribution streak
[ ] Top programming languages by public repo
[ ] Stars earned across public repos
[ ] Contribution heatmap (365-day grid)
Layer 2 — Output proof (what README stats misses)
[ ] Live stars and commit activity per specific named project
[ ] Project descriptions with tech stack, live URL, and status
[ ] Work experience with company, role, and dates
Layer 3 — Impact proof (what no widget can show)
[ ] Revenue figures for shipped products (MRR, ARR, total revenue)
[ ] Subscriber or paying customer counts
[ ] Custom metric strings ("42k users", "3.1M downloads")
Layer 4 — Reach proof
[ ] All relevant links consolidated in one place (GitHub, LinkedIn, blog, product URLs)
[ ] A shareable, indexable URL that search engines and AI tools can discover
[ ] A downloadable ATS resume that mirrors your live profile data
Most developers have Layer 1 from their GitHub profile and maybe a stats widget. The developers who consistently win job offers, consulting deals, and co-founder introductions have all four layers visible in one place.
For how the Proof Stack maps to a full developer personal brand strategy, see the Developer Personal Brand Guide.
FAQ#
What is GitHub README stats?#
GitHub README stats is a family of open-source widgets — primarily anuraghazra/github-readme-stats (79.7k GitHub stars) — that embed dynamic SVG cards in your GitHub profile README. They show commit counts, star totals, top programming languages, and contribution data pulled from GitHub's public API. You paste one image URL into a README markdown file and get an auto-updating card. No server required, no API keys, free to use.
How do I add GitHub stats to my profile README?#
Create a public repository named exactly your-github-username/your-github-username. GitHub auto-detects this and renders the README.md at the top of your profile. Add the widget URL to README.md: . Commit and push. The card appears immediately and updates from a rolling cache every 30 minutes to a few hours.
Does GitHub README stats count private repo commits?#
No — not by default. The widget reads GitHub's public API. With count_private=true in the URL, it can access the count of contribution events in private repos (but not their content or repo names), provided you've granted the necessary OAuth scope. For most visitors viewing your public profile page, only public repo activity appears in the stats card.
Why does my top languages card show the wrong languages?#
The top languages card counts bytes of code across your public repos, weighted by file size — not by proficiency or time spent. A large forked or legacy repo in a language you rarely use will dominate the breakdown. Fix it with &exclude_repo=repo-name to drop specific repos from the count, or &hide=java,html to exclude specific languages entirely.
Are GitHub README stats widgets reliable?#
Generally yes, with one known failure mode: the free public Vercel instance is subject to GitHub's API rate limit of 5,000 requests per hour. On high-traffic profiles, or during spikes, cards can display a "Max retries exceeded" error instead of your data. The project's issue tracker documented extended outages in late 2025. For consistent uptime during active job searches or client presentations, the maintainers recommend self-hosting on your own Vercel account rather than relying on the public instance.
What themes work best for GitHub README stats?#
The widget ships with over 30 themes: dark, radical, merko, gruvbox, tokyonight, onedark, cobalt, synthwave, dracula, and more. Add &theme=NAME to your widget URL. dark and tokyonight are the most common choices on GitHub's dark-mode interface. For a fully custom look, specify hex values directly in URL parameters with &title_color=, &text_color=, &icon_color=, and &bg_color=.
What's the best alternative to GitHub README stats for a complete developer profile?#
If the goal is a full, shareable developer presence — not just a widget on a README — purpose-built developer profile tools go further. DevBio (devbio.me) renders native components for commits, languages, contribution heatmap, per-project commit sparklines, and payment-verified revenue in one indexed web page, with a custom domain and a LaTeX PDF resume. For a comparison of the main developer profile formats and when to use each, see Developer Portfolio vs Personal Site vs Link in Bio.
Conclusion#
GitHub README stats widgets earn their 79,700 stars. For ten minutes of setup, you get real data on your GitHub profile — commit counts, language breakdowns, contribution streaks — visible to every recruiter or collaborator who lands there. With 180 million developers now on GitHub and one new developer joining every second according to Octoverse 2025, a stats-augmented README genuinely helps you stand out from a blank profile.
But know the ceiling. These widgets can't see your private-repo work — where most employed developers do their best code. They can't show revenue, users, or product outcomes. Their SVG format is invisible to search engines and AI crawlers. And they have no path to a resume.
The Proof Stack — activity, output, impact, and reach — is what a complete developer profile looks like in 2026. Layer 1 takes ten minutes. Layers 2 through 4 take a few hours once, and then your profile keeps itself current automatically.
Your code already proves you can build. Put it on one link — devbio.me