Is Web Scraping Legal in 2026? Practical Rules for Founders (US/EU)

Not legal advice.

Scraping is one of those topics where people want a one-line answer.

In reality, “Is web scraping legal?” depends on what you scrape, how you access it, what you do with it, and where you operate.

This guide is a practical 2026 playbook for founders shipping real products. We’ll focus on the US and EU because that’s where most SaaS companies end up selling.

We’ll cover:

• the 5 legal buckets that actually matter
• ToS vs robots.txt (and what they do not mean)
• public vs private data and authentication
• personal data (PII) and GDPR realities
• safe operating practices: rate limits, logging, opt-outs, and data minimization

The 5 buckets that matter more than “scraping”

When lawyers and courts analyze scraping disputes, they usually don’t argue about “scraping” as a concept. They argue about these buckets:

1. Unauthorized access / computer misuse
2. Contract (Terms of Service) and platform rules
3. Copyright and database rights (especially in the EU)
4. Privacy / personal data laws (GDPR, ePrivacy, state laws)
5. Unfair competition / misrepresentation

A scraping plan is “low risk” only if you’ve thought through all five.

Bucket 1: Unauthorized access (US + EU conceptually)

US: CFAA is the headline risk

In the US, the Computer Fraud and Abuse Act (CFAA) shows up in many scraping fights.

Founder translation:

• scraping public pages is generally safer than scraping behind login
• bypassing technical barriers (accounts, paywalls, CAPTCHAs, IP blocks) can raise risk
• using stolen credentials or circumventing access controls is high risk

There have been important cases about public data and “authorization,” but founders shouldn’t bet the company on a single legal interpretation.

EU: “unauthorized access” exists too

EU countries have their own computer misuse laws. If you scrape by breaking access controls, you’re in a worse position.

Practical rule:

• If you need to defeat authentication or access control to get the data, stop and reassess.

Bucket 2: Terms of Service (ToS) and what it means in practice

A ToS is a contract. If you use a site, you may be agreeing to it.

Founder reality:

• violating ToS may be a contract breach claim
• ToS breach is not automatically a crime, but it can become leverage in a dispute
• enforcement varies widely; some companies ignore it, others litigate aggressively

Practical rules:

• If you’re scraping a business-critical target, read their ToS like you’re reading an API contract.
• If the ToS forbids automated access, consider:
  • alternative sources (partners, public datasets)
  • official APIs
  • reduce frequency and scope (data minimization)

robots.txt: important, but not law

Robots.txt is a technical convention for crawler permissions.

• It is not a law.
• It can still matter:
  • it shows “intent”
  • it can be referenced in disputes
  • it’s a good governance signal

Practical rule:

• If robots.txt disallows your path, treat it as a serious warning. If you proceed, you should have a clear, documented rationale.

Bucket 3: Copyright + EU database rights

US: facts aren’t copyrighted, expression can be

In the US:

• raw facts (e.g. “price is $19.99”) aren’t usually copyrighted
• the presentation (text, images, reviews, UI) can be

So copying:

• a price point is different from copying the full product description and photos

Practical rule:

• scrape the minimum you need (facts/metadata) and avoid copying creative content.

EU: database rights can bite

The EU has database rights that can be triggered by substantial extraction/reuse.

Founder translation:

• even if the individual items are “facts,” wholesale copying of a database can be risky
• building a “complete mirror” of a directory site is a higher-risk move

Practical rule:

• avoid building a 1:1 replica dataset for a specific target; focus on:
  • aggregation across many sources
  • transformation and derived insights
  • limited, purpose-bound extraction

Bucket 4: Personal data (PII) and GDPR

If you’re scraping anything that identifies a person, you’re in GDPR territory for EU users.

Examples of personal data:

• names tied to profiles
• emails, phone numbers
• photos
• unique identifiers
• “this person reviewed this business” can be personal data

GDPR founder reality:

• you need a lawful basis (often legitimate interest)
• you must minimize data
• you must secure data
• you should have retention policies
• you may need to honor deletion requests

Practical rules:

• Avoid collecting user-generated content (UGC) at scale unless you have a clear lawful basis.
• If you must collect UGC, collect less:
  • store aggregate sentiment, not usernames
  • hash identifiers
  • keep raw data short-lived

Bucket 5: Unfair competition and “don’t be shady” law

Even if scraping is technically possible, you can still get into trouble if you:

• misrepresent who you are
• disrupt a service
• copy a competitor’s dataset and sell it as-is

Practical rule:

• If your product looks like “we copied their thing,” expect conflict.

A practical risk checklist (use this before you write code)

Access

• Are the pages public (no login)?
• Are you bypassing a paywall, login, or “block” page?

Contract / platform rules

• Have you read ToS for automated access restrictions?
• Do you have a fallback plan if they send a cease-and-desist?

Data type

• Are you collecting facts/metadata or copying creative content?
• Are you collecting personal data? If yes, do you have GDPR posture?

Volume / impact

• Rate limits implemented?
• Exponential backoff on errors?
• Caching / change detection to reduce load?

Governance

• Logs for what you collected + when?
• Retention policy?
• Opt-out / takedown workflow?

If you can’t answer these, you don’t have a scraping strategy — you have a liability.

How to reduce risk while still shipping

1) Data minimization (the biggest lever)

Collect only what you need.

Bad:

• mirror entire pages

Good:

• extract price, availability, SKU identifiers
• store an HTML hash + URL as evidence

2) Prefer public endpoints and official APIs

If a platform provides a stable API, it’s often less risky than scraping. It may be more expensive, but it’s easier to defend.

3) Use reasonable rate limits

A good citizen scraping system:

• spreads requests
• backs off on errors
• doesn’t hammer a single host

4) Keep evidence without copying content

If you need “proof,” you can store:

• timestamp
• URL
• extracted fields
• screenshot on violation

You don’t necessarily need to store full page HTML forever.

5) Establish a takedown process

Even if you believe you’re in the right, having an easy opt-out path is a practical conflict reducer.

US vs EU: founder-friendly differences

US (roughly)

• contract claims are common (ToS)
• unauthorized access arguments show up (CFAA)
• facts vs expression matters for copyright

EU (roughly)

• GDPR is more central
• database rights can matter
• cross-border enforcement can be complex

Practical founder take:

• if you operate in the EU or serve EU customers, plan for GDPR compliance early.

Where ProxiesAPI fits (and where it doesn’t)

ProxiesAPI can make your collection layer more stable — it’s a network tool.

It does not:

• grant permission
• override ToS
• remove GDPR obligations

So treat it as infrastructure, not a legal strategy.

Summary

Scraping can be legal, but it’s not “free.”

If you want to build a durable business around scraped data:

• keep access public and above-board
• minimize what you collect
• avoid personal data unless you have a real compliance posture
• rate limit and log everything
• design for takedowns and change

That’s what makes scraping sustainable in 2026.