A GitHub search for "facebook scraper" returns 475 repositories. Only 62 of them have been pushed in the last six months.
That gap between "available" and "actually works" is the whole story of Facebook scraping on GitHub in 2026.
I've spent a lot of time digging through repo issue tabs, Reddit complaints, and actual output from these tools. The pattern is consistent: most top-starred projects are quietly broken, maintainers have moved on, and Facebook's anti-scraping defenses keep getting sharper. Developers and business users keep landing on the same search results, installing the same repos, and running into the same empty output. This article is a 2026 reality check — an honest audit of which repos still deserve your time, what Facebook is doing to break them, and when you should skip GitHub entirely.
Why People Search for a Facebook Scraper on GitHub
The use cases behind this search are the same ones that have existed for years — even if the tools keep falling apart:
- Lead generation: Extracting business page contact info (emails, phone numbers, addresses) for outreach
- Marketplace monitoring: Tracking product listings, prices, and seller info for ecommerce or arbitrage
- Group research: Archiving posts and comments for market research, OSINT, or community management
- Content and post archiving: Saving public page posts, reactions, images, and timestamps
- Events aggregation: Pulling event titles, dates, locations, and organizers
GitHub's appeal is obvious: visible code, zero cost, community maintenance (theoretically), and full control over fields and pipelines.
The problem is that stars and forks don't correlate with "currently functional." Among the top 10 exact-phrase repos by stars, all 10 were more than 12 months stale as of April 2026. That's not a fluke — it's the norm.
One Reddit user in a November 2025 thread put it plainly after six months of trying: it was "impossible without either paying for an external data scraping application" or using Python plus JS rendering plus significant computation power. Another, in an April 2026 discussion, summarized it as: "Facebook is one of the harder ones to scrape because they aggressively block automation" and browser automation is "fragile since Facebook changes their DOM constantly."
The use cases are real. The demand is real. The frustration is very real. The rest of this article is about navigating that gap.
What Is a Facebook Scraper GitHub Repo, Exactly?
A "Facebook scraper" on GitHub is an open-source script — usually Python — that programmatically extracts public data from Facebook pages, posts, groups, Marketplace, or profiles. Not all of them work the same way. Three architectures dominate:
Browser-Automation Scrapers vs. API Wrappers vs. Direct HTTP Scrapers
| Approach | Typical stack | Strength | Weakness |
|---|---|---|---|
| Browser automation | Selenium, Playwright, Puppeteer | Can handle login walls, mimics real user behavior | Slow, resource-heavy, easy to fingerprint if not configured carefully |
| Official API wrapper | Meta Graph API / Pages API | Stable, documented, compliant when approved | Severely restricted — most public post/group data is no longer available |
| Direct HTTP scraper | requests, HTML parsing, undocumented endpoints | Fast and lightweight when it works | Breaks whenever Facebook changes page structure or anti-bot measures |
kevinzg/facebook-scraper is the classic direct-HTTP example: it scrapes public pages "without an API key" using direct requests and parsing. apurvmishra99/facebook-scraper-selenium is a browser-automation example. minimaxir/facebook-page-post-scraper represents the old Graph API era, where scripts could pull page/group posts through official endpoints that are no longer broadly available.
Typical target data across these repos includes post text, timestamps, reaction/comment counts, image URLs, page metadata (category, phone, email, follower count), Marketplace listing fields, and group or event metadata.
In 2026, the real tradeoff isn't language preference. It's which kind of failure you can tolerate.
The 2026 Facebook Scraper GitHub Freshness Audit: Which Repos Actually Work?
I audited the most-starred and most-recommended Facebook scraper repos on GitHub against real 2026 data — not README claims, but actual commit dates, issue queues, and community reports. This is the section that matters most.
The Full Freshness Audit Table
| Repo | Stars | Last Push | Open Issues | Language / Runtime | What It Still Scrapes | Status |
|---|---|---|---|---|---|---|
| kevinzg/facebook-scraper | 3,157 | 2024-06-22 | 438 | Python ^3.6 | Limited public page posts, some comments/images, page metadata | ⚠️ Partially broken / stale |
| moda20/facebook-scraper | 110 | 2024-06-14 | 29 | Python ^3.6 | Same as kevinzg + Marketplace helper methods | ⚠️ Partially broken / stale fork |
| minimaxir/facebook-page-post-scraper | 2,128 | 2019-05-23 | 53 | Python 2/3 era, Graph API dependent | Historical reference only | ❌ Abandoned |
| apurvmishra99/facebook-scraper-selenium | 232 | 2020-06-28 | 7 | Python + Selenium | Browser automation for page scraping | ❌ Abandoned |
| passivebot/facebook-marketplace-scraper | 375 | 2024-04-29 | 3 | Python 3.x + Playwright 1.40 | Marketplace listings via browser automation | ⚠️ Fragile / niche |
| Mhmd-Hisham/selenium_facebook_scraper | 37 | 2022-11-29 | 1 | Python + Selenium | General Selenium scraping | ❌ Abandoned |
| anabastos/faceteer | 20 | 2023-07-11 | 5 | JavaScript | Automation-oriented | ❌ Risky / low proof |
A few things jump out:
- Even the "active fork" (moda20) hasn't been pushed since June 2024.
- Issue queues tell the real story faster than READMEs.
- Both kevinzg and moda20 still declare Python ^3.6 in their pyproject.toml files — a signal that the dependency baseline hasn't been modernized.
kevinzg/facebook-scraper
The best-known Python Facebook scraper on GitHub. Its README describes page scraping, group scraping, login via credentials or cookies, and post-level fields like comments, image, images, likes, post_id, post_text, text, and time.
The operational signal, though, is weak:
- Last push: June 22, 2024
- Open issues: 438 — including titles like "Example Scrape does not return any posts"
- The maintainer has not responded to recent issues
Verdict: Partially broken. Still has value for low-volume public page experiments and as a field-name reference, but not reliable for production use.
moda20/facebook-scraper (Community Fork)
The most visible fork of kevinzg, with added options and Marketplace-oriented helpers like extract_listing (documented in its README).
The issue queue makes the breakage story explicit:
- "mbasic is gone"
- "CLI 'Couldn't get any posts.'"
- "https://mbasic.facebook.com is no longer working"
When the simplified mbasic frontend changes or disappears, a whole class of scrapers degrades at once.
Verdict: The most notable fork, but also stale and fragile in 2026. Worth trying first if you insist on a GitHub-based solution, but don't expect stability.
minimaxir/facebook-page-post-scraper
Once a very practical Graph API tool for gathering posts, reactions, comments, and metadata from public Pages and open Groups into CSVs. Its README still explains how to use a Facebook app's App ID and App Secret.
In 2026, it's a historical artifact:
- Last push: May 23, 2019
- Open issues: 53 — including "HTTP 400 Error Bad Request" and "No data retrieved!!"
Verdict: Abandoned. Tightly coupled to an API permission model Meta has since narrowed substantially.
Other Notable Repos
- passivebot/facebook-marketplace-scraper: Useful for Marketplace use cases, but its issue queue includes "login to view the content," "CSS selectors outdated," and "Getting blocked." A one-line case study of what breaks on Marketplace scraping.
- apurvmishra99/facebook-scraper-selenium: Has one issue literally asking "Does it work with new Facebook layout?" from September 2020. That tells you almost everything.
- Mhmd-Hisham/selenium_facebook_scraper and anabastos/faceteer: Neither has enough current activity to justify confidence.

Facebook's Anti-Scraping Defenses: What Every GitHub Scraper Is Up Against
Most articles on this topic offer vague "check the ToS" disclaimers. That's not useful.
Facebook has one of the most aggressive anti-scraping systems of any major platform. Understanding the specific defense layers is the difference between a working scraper and an afternoon of empty output.
Meta's own February 2025 engineering post describes an "Anti Scraping team" that uses static analysis across its codebase to identify scraping vectors, sends cease-and-desist letters, disables accounts, and relies on rate-limiting systems. That's not a hypothetical — it's an organizational commitment.

Randomized DOM and CSS Class Names
Facebook deliberately randomizes HTML element IDs, class names, and page structure. As one r/webscraping commenter put it: "No normal scraper can work on Facebook. The HTML mutates between refreshes."
What breaks: XPath and CSS selectors that worked last week return nothing today.
Countermeasure: Use text-based or attribute-based selectors when possible. AI-based parsing that reads page content rather than relying on rigid selectors handles this better. Expect selector maintenance as a recurring cost.
Login Walls and Session Management
Many Facebook surfaces — profiles, groups, some Marketplace listings — require login to view. Headless browsers get redirected or served stripped-down HTML. The passivebot Marketplace scraper's issue tab has "login to view the content" as a top complaint.
What breaks: Anonymous requests miss content or redirect entirely.
Countermeasure: Use session cookies from a real browser session, or browser-based scraping tools that operate within your logged-in session. Rotating accounts is possible but risky.
Digital Fingerprinting
Meta's engineering post says unauthorized scrapers "commonly hide themselves by mimicking the ways users would normally use a product" — which is effectively a statement that browser-quality and behavior-quality are central to detection. Community discussions in March and April 2026 continue to recommend anti-detect browsers and consistent fingerprints.
What breaks: Standard off-the-shelf Selenium or Puppeteer setups are easily identified.
Countermeasure: Use tools like undetected-chromedriver or anti-detect browser profiles. Realistic sessions and consistent fingerprints matter more than simple user-agent spoofing.
IP-Based Rate Limiting and Blocking
Meta's engineering post explicitly discusses rate limiting as part of the defense strategy, including capping follower-list counts to force more requests that then trip rate controls. In practice, users report getting rate-limited after posting to 10 groups at 10-second intervals.
What breaks: Bulk requests from the same IP get throttled or blocked within minutes. Datacenter proxy IPs are often pre-blocked.
Countermeasure: Residential proxy rotation (not datacenter proxies), with sensible request pacing.
GraphQL Schema Changes
Some scrapers rely on Facebook's internal GraphQL endpoints because they return cleaner structured data than raw HTML. But Meta doesn't publish a stability guarantee for internal GraphQL, so these queries break silently — returning empty data instead of errors.
What breaks: Structured extraction silently returns nothing.
Countermeasure: Add validation checks, monitor schema endpoints, and pin to known working queries. Expect maintenance.
Anti-Scraping Defense Summary
| Defense Layer | How It Breaks Your Scraper | Practical Countermeasure |
|---|---|---|
| Layout churn / unstable selectors | XPath and CSS selectors return nothing or partial fields | Prefer resilient anchors, validate against visible page output, expect maintenance |
| Login walls | Logged-out requests miss content or redirect | Use valid session cookies or browser-session tools |
| Fingerprinting | Standard automation looks synthetic | Use real browsers, consistent session quality, anti-detect measures |
| Rate limiting | Empty output, blocks, throttling | Slow pacing, lower batch sizes, residential proxy rotation |
| Internal query changes | Structured extraction silently returns empty data | Add validation checks, expect query maintenance |
When GitHub Repositories Fail: Choose a Permitted Alternative
A broken repository is not a reason to look for another way around a platform's controls. First clarify the business question: do you need page-level analytics, advertising transparency, a public contact directory, or a product catalogue? Many of those needs can be met with an official Meta product, a permissioned API, or a non-Meta public source.
For example, use the Graph API only when the app and use case have the required permissions, use Meta research programmes only when eligible, and use Meta Ad Library for the advertising information it makes available. For lead research, pricing, and local-business discovery, prefer independent public websites whose terms and privacy obligations you can assess directly.
Real Output Samples: What You Actually Get
Every competitor article shows code snippets but never the actual output. Below is what you can realistically expect from each approach.
Sample Output: kevinzg/facebook-scraper (or Active Fork)
From the README example, a scraped public post returns JSON like:
{
"comments": 459,
"comments_full": null,
"image": "https://...",
"images": ["https://..."],
"likes": 3509,
"post_id": "2257188721032235",
"post_text": "Don't let this diminutive version...",
"text": "Don't let this diminutive version...",
"time": "2019-04-30T05:00:01"
}
Note the nullable fields like comments_full. In 2026, expect more fields to come back empty or missing — that's usually a blocking signal, not a harmless glitch. The output is raw JSON and requires post-processing.
Sample Output: Facebook Graph API
Meta's current Pages API documents page info requests like GET /<PAGE_ID>?fields=id,name,about,fan_count. The Page reference includes fields such as followers_count, fan_count, category, emails, phone, and other public metadata — but only with the right permissions like Page Public Content Access or Page Public Metadata Access.
That's a much narrower data shape than most GitHub scraper users expect. It's page-centric, permission-gated, and not a substitute for arbitrary public-post or group scraping.
Facebook Data Type Ă— Access Route Matrix
| Facebook data type | Preferable starting point | Key limitation |
|---|---|---|
| Assets your organisation administers | Official Meta management tools and approved APIs | Permissions and available fields vary |
| Advertising observations | Meta Ad Library | Use only fields and filters it exposes |
| Public business details needed for lead research | A permitted non-Meta directory or publisher site | Verify the source's terms and privacy obligations |
| Private, closed-group, login-gated, or account-only material | Do not automate collection | Seek an authorised path instead |
Step-by-Step: How to Set Up a Facebook Scraper from GitHub (When It Makes Sense)
If you've read the freshness audit and still want to go the GitHub route, fair enough. Here's the practical path — with honest notes about where things break.

Step 1: Choose the Right Repo (Use the Freshness Audit)
Refer back to the audit table. Pick the least stale repo that matches your target surface. Before installing anything, check the Issues tab — recent issue titles tell you more about current functionality than the README does.
Step 2: Set Up Your Python Environment
python3 -m venv fb-scraper-env
source fb-scraper-env/bin/activate
pip install -r requirements.txt
Common gotcha: version conflicts with dependencies, especially Selenium/Playwright versions. Both kevinzg and moda20 declare Python ^3.6 in their pyproject.toml — an older baseline that may conflict with newer libraries. passivebot's Marketplace scraper pins playwright==1.40.0, which is fine for experimentation but not proof of durability.
Step 3: Configure Proxies and Anti-Detection
If you're doing anything beyond a quick test:
- Set up residential proxy rotation (look for providers with Facebook-specific IP pools)
- If using browser automation, install undetected-chromedriver or configure anti-fingerprinting
- Don't skip this step — standard Selenium or Puppeteer gets flagged fast
Step 4: Run a Small Test Scrape and Validate Output
Start with a single public page, not a large batch. Check the output carefully:
- Empty fields or missing data usually mean Facebook's defenses are blocking you
- Compare output against what you actually see on the page in your browser
- A successful one-page test matters more than a pretty README
Step 5: Handle Errors, Rate Limits, and Maintenance
- Build in retry logic and error handling
- Expect to update selectors or configurations regularly — this is ongoing maintenance, not set-and-forget
- If you find yourself spending more time maintaining the scraper than using the data, that's a signal to reconsider the no-code path
Legal and Ethical Considerations for Facebook Scraping
Platform terms, privacy rules, contractual obligations, and data-protection laws can all apply. Public visibility is not a blanket authorisation for automated collection. Keep data minimised, document the purpose and lawful basis, and obtain legal advice for commercial or large-scale programmes.
Do not treat a browser extension, a logged-in session, or a “public” label as permission to automate collection from Meta products.
Key Takeaways: What Actually Works for Facebook Scraping in 2026
Repository activity, issue queues, and current platform rules matter more than a star count or old README. When the business question concerns an asset you administer, start with official Meta tools and approved APIs. For market research, lead research, and pricing questions, a permitted non-Meta source is often easier to document and govern.
FAQs
Is there a working Facebook scraper on GitHub in 2026?
Yes, but options are limited. The most notable is the moda20/facebook-scraper fork of kevinzg's original repo — check the freshness audit table above for current status. It can partially scrape public page posts and some metadata, but its issue queue shows core breakage around mbasic and empty output. Most other repos are abandoned or fully broken.
Can I scrape Facebook without coding?
Use Facebook's own search and management tools for manual research. For repeatable or programmatic work, assess the official API and its permissions, or redesign the workflow around a permitted non-Meta source. No-code convenience does not remove platform, privacy, or contractual obligations.
Is it legal to scrape Facebook?
Facebook's Terms of Service prohibit automated data collection without permission. Meta actively enforces this through account bans, cease-and-desist letters, and lawsuits. Legality varies by jurisdiction and use case. Stick to publicly available business data, avoid personal profiles, and consult legal counsel if operating at scale.
What data can I still get from the Facebook Graph API?
In 2026, the Graph API is heavily restricted. You can access limited page-level data — fields like id, name, about, fan_count, emails, phone — with proper permissions such as Page Public Metadata Access. Most public post data, group data (the Groups API is deprecated), and user-level data are no longer available via API.
How often do Facebook scraper GitHub repos break?
Frequently. Facebook changes its DOM structure, anti-bot measures, and internal APIs on an ongoing basis — there's no published cadence, but community reports show breakage every few weeks for active scrapers. The moda20 fork's issue queue around mbasic disappearance is a recent example. If you rely on a GitHub repo, budget for regular maintenance and output validation.
Learn More


