Is Web Scraping Legal? What hiQ and Meta v. Bright Data Actually Held

Two cases get quoted in every argument about this, usually as a single sentence each: hiQ v. LinkedIn — "scraping public data is legal," and Meta v. Bright Data — "the court said scraping doesn't breach the terms of service."

Both sentences are wrong in ways that matter. hiQ won on the statute and then lost on the contract, paid $500,000, and agreed to a permanent injunction. Meta v. Bright Data turned on two words in Meta's own terms, and the ruling would have gone differently had Bright Data been logged in.

Here is what the decisions say, what they left open, and the three separate questions that get collapsed into "is scraping legal."

This is not legal advice. It is a developer's reading of published decisions, written by engineers. Scraping law is jurisdiction-dependent and fact-specific — the same code can be unremarkable in one country and actionable in another, and the difference usually turns on details of your particular setup. Talk to a lawyer about your situation before relying on any of this.

The short answer, and the three questions it depends on

There is no law called the Web Scraping Act. "Is scraping legal" resolves into at least three questions with different answers, different plaintiffs, and different consequences:

Question	Governed by	Who sues you	What it turns on
Is it unauthorised computer access?	Computer Fraud and Abuse Act (US); equivalents elsewhere	Platform, or a prosecutor	Whether you passed a technical gate — a login, an IP block, a revocation
Did you break a promise?	Contract — the terms of service	Platform	Whether you agreed to the terms, and whether they cover what you did
May you process this data at all?	GDPR, CCPA and similar	A regulator, or the people in the data	Whether it is personal data and whether you have a lawful basis

A clean win on the first two says nothing about the third. That is the single most common mistake in this category, and it has its own post: not breaching a platform's terms is not a lawful basis under GDPR.

hiQ v. LinkedIn: won the statute, lost the contract

hiQ Labs built an employee-attrition product on public LinkedIn profiles. In May 2017 LinkedIn sent a cease-and-desist letter invoking the CFAA and blocked hiQ's access. hiQ sued.

When	What happened
Aug 2017	N.D. Cal. grants hiQ a preliminary injunction; LinkedIn must remove technical barriers
Sep 2019	Ninth Circuit affirms — hiQ Labs, Inc. v. LinkedIn Corp., 938 F.3d 985
Jun 2021	Supreme Court vacates and remands in light of Van Buren v. United States
Apr 2022	Ninth Circuit affirms again — 31 F.4th 1180
Aug 2022	District court dissolves the injunction: hiQ had effectively ceased operating
Nov 2022	Summary judgment for LinkedIn on breach of contract
Dec 2022	Stipulated judgment: $500,000 and a permanent injunction against hiQ

What hiQ won. The Ninth Circuit held that the CFAA's "without authorization" concept does not fit a public website. The statute protects computers where authorisation is required, which the Supreme Court in Van Buren v. United States, 593 U.S. 374 (2021), described as a gates-up-or-down inquiry: either a gate is closed to you or it is not. The Ninth Circuit applied that reading to public pages. On a page any browser can load, there is no gate. Scraping it is not hacking.

That holding is real, and it is binding precedent in the Ninth Circuit. It is also narrower than the headline: it is about one federal statute, and it was decided on a preliminary-injunction posture.

What hiQ lost. In November 2022 the district court held that hiQ had breached LinkedIn's User Agreement in two ways: automated scraping, and hiring crowdsourced workers to create fake profiles. hiQ had a corporate LinkedIn account and had agreed to the terms when it created one. The CFAA holding did not help, because breach of contract is a different claim.

Weeks later the parties stipulated to a $500,000 judgment and a permanent injunction requiring hiQ to stop scraping and destroy the source code, data and algorithms derived from LinkedIn profiles. As part of that stipulation hiQ conceded LinkedIn could establish CFAA liability — a negotiated concession in a settlement, not a court holding, and not precedent. But the practical outcome is unambiguous: the company that won the landmark public-scraping case no longer exists.

The lesson is not "hiQ was wrong." It is that the CFAA was never the binding constraint. The account was.

Meta v. Bright Data (2024): "your use" did the work

Meta sued Bright Data in January 2023 for breach of contract and tortious interference, over scraping of public Facebook and Instagram data and the resale of it.

On 23 January 2024, Judge Edward Chen granted summary judgment for Bright Data on the contract claims (Meta Platforms, Inc. v. Bright Data Ltd., No. 3:23-cv-00077-EMC, N.D. Cal.). The reasoning is ordinary contract interpretation, not a grand principle:

• Meta's terms govern "your use" of the products. The court read that as binding people while they are using the service as users.
• Bright Data held Facebook and Instagram accounts, but the court found those accounts incidental and unrelated to the scraping, which was done logged off.
• Facebook's terms contain a survival clause purporting to prohibit scraping in perpetuity, including after an account is closed. The court declined to read it as reaching logged-off conduct. Instagram's terms had no survival clause at all.

On 23 February 2024 Meta dismissed its one remaining claim without prejudice and waived its right to appeal the summary-judgment order. The case terminated three days later. Bright Data changed nothing about its conduct and paid nothing.

Why "logged out" is doing all the work. Every load-bearing step above depends on Bright Data not being logged in. Had the scraping run through an authenticated session, "your use" would have covered it, the accounts would not have been incidental, and the case would likely have gone the other way. This is the distinction worth designing your system around, and it has its own post on why logged-out is the defensible posture.

It is also one district judge reading one company's terms. Different wording produces a different result.

Three more cases people don't cite, and should

X Corp. v. Bright Data (N.D. Cal., 9 May 2024). Judge William Alsup dismissed X's claims over scraping and reselling public posts. Contract claims based on access to the public site failed; claims premised on copying public content were preempted by the Copyright Act. The opinion warns that giving platforms free rein to decide who may collect data "that the companies do not own, that they otherwise make publicly available to viewers" risks "the possible creation of information monopolies that would disserve the public interest."

Ryanair DAC v. Booking.com (D. Del.). The contrast case. Booking.com obtained fares by accessing the password-protected myRyanair portion of the site through a partner. In July 2024 a jury found a CFAA violation and awarded $5,000 — exactly the statutory minimum loss a civil CFAA claim must clear. In March 2025 the court granted judgment as a matter of law for Booking.com, finding Ryanair had not actually proven $5,000 in qualifying loss. The case is on appeal to the Third Circuit. Two things to take from it: a login moves you onto genuinely contested CFAA ground, and CFAA damages in a scraping case are hard to prove.

Reddit v. Perplexity AI (S.D.N.Y., filed 22 October 2025). The newest theory, and the one to watch. Reddit sued Perplexity along with three data-collection intermediaries, pleading not the CFAA but the DMCA's anti-circumvention provision, 17 U.S.C. §1201 — alleging the defendants evaded rate limits and anti-bot measures to harvest Reddit content from search-result pages. Motions to dismiss were argued on 30 June 2026. As of August 2026 there is no ruling. If circumvention theories succeed, "the data was public" stops being a complete answer, because the claim is about the measures you got past rather than the page you reached.

Copyright and database rights: where the US and EU diverge

US law is comparatively friendly here. Facts are not copyrightable, a thin compilation copyright protects selection and arrangement rather than the underlying data, and X Corp. v. Bright Data shows courts willing to preempt state-law claims that function as copyright claims in disguise.

The EU is not the same place. The sui generis database right protects substantial investment in obtaining and presenting a database's contents, independent of copyright. And in Ryanair Ltd v PR Aviation BV (CJEU, C-30/14, 2015) the Court held that where a database falls outside the Database Directive's protection, the directive does not stop the owner from imposing contractual restrictions on its use. In other words: in the EU, a database that is not protected by the database right can still be protected by its terms of use. The US intuition that "the terms don't matter for public data" travels badly.

Personal data is a separate question entirely

Nothing above is about privacy law. hiQ is about a US computer-crime statute. Bright Data is about a contract. If the rows you are collecting include a name, a handle attached to a real person, a photograph or an email address, and any of those people are in the EU or UK, you have a data-protection question that no US contract ruling answers. That is the subject of scraping and GDPR.

A practical checklist before you scrape anything

Not advice — the questions we ask ourselves before adding an endpoint.

1. Can you get this data without an account? If not, everything above gets harder. If yes, stay logged out and keep it that way.
2. Have you accepted terms with this platform for any reason? A company account for ads or a developer account can bring you inside a contract you did not think applied.
3. Is there a sanctioned API? Regulator-mandated archives such as the Meta Ad Library and its official Graph API are the lowest-risk data in this category, because the platform is required to publish them.
4. Are you getting past a technical measure? Rate limits, bot challenges and IP blocks are the raw material of §1201 and revocation arguments. Treat them as signals, not obstacles.
5. Did a letter arrive? A cease-and-desist can change your legal position even for public data. What that ladder looks like in practice is covered here.
6. Is it personal data, and whose? Ask before you collect it, not when a request to delete it arrives.
7. What do you do with it? Reselling, republishing, or training on the data raises questions that merely reading it does not.

What we do, and why

We collect public data, logged out. We hold no accounts on the platforms we read, use no credentials and no session cookies, and do not get past login walls. Where a platform publishes an official API for the data, we build on that instead of scraping the interface — our Meta Ad Library endpoints use Meta's Graph API, and are currently waiting on an access token rather than on anything to do with access control.

That posture costs us coverage. Some data is only visible to a signed-in user, and we do not have it. We think the trade is correct given how Meta v. Bright Data was decided, and given that the alternative is building a business on the exact fact pattern that has lost.

It is a choice about our own risk, not a recommendation about yours, and it is not a guarantee of anything. Nobody scraping the web today has one.