Is Web Scraping GDPR Compliant? A Plain-English Guide (2026)

Scraping publicly available, non-personal data is generally GDPR-compliant. Scraping data that can identify a living person needs a lawful basis. And if you're pulling names, emails, profile photos, or anything else tied to a real person, you're already in GDPR territory. This guide shows you how to tell the two apart and stay on the right side of the rules.

Who this is for: engineers, product teams, and compliance leads who scrape at scale.

First, let's kill the most common misconception. GDPR does not give data a free pass just because it's sitting out in the open. If it identifies a person, it's personal data, even if anyone can see it. A product price isn't personal data. A seller's name is next to that listing. The rest of this guide, Web Scraping GDPR Compliant, walks through where exactly that line falls, what regulators have actually done about it, and how to figure out, before you write any scraper code, whether your project is safe.

Web Scraping GDPR Compliant: Personal vs non-personal data: where the line sits

What GDPR enforcement actually looks like for scrapers

Most "is scraping legal" articles stop at theory. So here's what regulators have done in practice. The pattern is remarkably consistent: the fine almost always comes down to processing personal data without a lawful basis, or failing to tell people you collected their data. It's never the scraping itself. In fact, the most common GDPR violation across the EU is insufficient legal basis for processing, which is exactly what went wrong in every case below.

The cases that are actually about scraping

KASPR is the clearest modern example (CNIL, €240,000, December 2024).

 

KASPR sold a paid Chrome extension that pulled professional contact details off LinkedIn, and built a database of around 160 million contacts. France's data protection authority fined them €240,000. The key finding is the one to remember: KASPR collected contact details from users who had deliberately limited who could see their information, which went well beyond what those people would reasonably expect. On top of that, KASPR held the data too long, didn't tell people it had collected them (no notice at all until 2022, and then only in English), and when people asked where their data came from, the company just said "publicly available sources." The case was closed in 2026 once KASPR fixed things. The takeaway: public visibility isn't consent, and "we found it online" is not an acceptable answer to someone asking about their own data.

Clearview AI is the biometric extreme (Dutch DPA €30.5M, roughly €100M EU-wide).

Clearview scraped billions of public photos from social media and the wider web to build a facial-recognition database, then sold it to law enforcement. The Dutch regulator fined them €30.5 million for handling biometric data with no lawful basis, no transparency, and no EU representative. France, Italy, and Greece piled on with their own penalties. Again, the photos were public, and it didn't matter. Scraping personal data at scale without a lawful basis, especially something as sensitive as biometric data, is well within GDPR's reach, even when the company has no office in Europe.

Bisnode in Poland set the notification precedent (Polish DPA, €220,000, 2019). 

This was Poland's first-ever GDPR fine, and it's still the go-to case on the duty to tell people. A data broker scraped contact data on roughly 5.7 million people from public business registries, then chose not to notify most of them because postal notices would have cost millions. The company called that a "disproportionate effort." The regulator didn't buy it. Since the company already had the contact details, notifying people was doable and therefore required under Article 14. A privacy notice buried on its own website wasn't enough. Lesson: if you scrape someone's personal data from somewhere other than them directly, you usually have to tell them within a month, and "it was too expensive" won't get you off the hook.

hiQ v. LinkedIn gets cited constantly, but it isn't a GDPR case.

hiQ scraped public LinkedIn profiles, LinkedIn tried to block it, and US courts (the 9th Circuit) ruled that scraping publicly accessible data doesn't break the Computer Fraud and Abuse Act, which is a US anti-hacking law. That's a point about US access law, not European privacy law. hiQ tells you that scraping public pages probably isn't "hacking" in the US. It says nothing about whether processing the personal data on those pages is okay under GDPR. People mix these two up all the time, so don't.

The scale regulators operate at (not scraping, but worth knowing)

None of these are scraping cases, but they show you how big the numbers can get. GDPR fines can reach €20 million or 4% of global annual turnover, whichever is larger, and regulators are clearly willing to use that power. Total GDPR fines have now passed €7 billion across more than 2,800 enforcement actions since 2018.

• TikTok, €530M (Irish DPC, May 2025): the biggest fine of 2025, for unlawfully sending EEA user data to China and not being upfront about it. This is a data-transfer case.

• Google €325M and Shein €150M (CNIL, September 2025): both for cookie-consent and ad-tracking problems. These technically fall under the ePrivacy cookie rules that sit next to GDPR rather than GDPR itself, but they're part of the same enforcement push.

• Amazon, €746M (Luxembourg, 2021): for targeted-advertising consent, and the biggest GDPR fine on record at the time. One caveat: the fine was thrown out on procedural grounds in March 2026 and sent back to the regulator, though the underlying findings stood. So treat it as a sense of the scale that's possible, not a settled precedent.

The contrast says everything. The headline-grabbing fines aren't about scraping at all. The scraping fines (KASPR, Clearview, Bisnode) are smaller in euros, but they're the ones that actually tell you where the line is.

Platform-by-platform risk

Why e-commerce data is the safe harbor

If GDPR risk is what's keeping you up at night, the simplest fix is structural: scrape the kinds of data the regulation doesn't touch in the first place. Product catalogs, sizes and units, SKUs, pricing, stock levels, specs. None of it has a data subject behind it, so there's no lawful basis to establish, nobody to notify, and no erasure request to worry about. That's exactly why price intelligence, competitor monitoring, MAP compliance, and catalog enrichment are the lowest-risk ways to use web data at scale.

For most businesses, the smart play isn't to wade into personal-data scraping with a legitimate-interests assessment and hope it holds up. It's to get really good at e-commerce data hygiene: clean, deduplicated, normalized product data that's ready to feed straight into analytics or AI. Put your effort there, run the occasional "is our data AI-ready" audit, and you get all the upside of web data while quietly sidestepping the heaviest GDPR liabilities. Building safe by design beats firefighting compliance later.

The enrichment gray area: clean it before you store it

Here's a trap that doesn't show up in the table above, because it happens after you scrape. You can pull a perfectly clean, non-personal dataset, say a few million product reviews, and then accidentally turn it back into personal data when you process it. Run those reviews through an LLM for sentiment analysis or entity extraction and you might scoop up reviewer usernames, signatures, or oddly specific regional phrasing that points to a real person. Now you're processing personal data again, whether you meant to or not.

The fix is to add a cleaning step between scraping and storage. Strip out usernames, handles, and free-text identifiers, and run a PII filter or redaction pass before any of it lands in your production database. Think of "raw scraped data" and "stored analytics data" as two separate stages with a data-cleaning gate sitting between them. That single step closes a gap most compliance checklists miss entirely.

A quick decision flow for lawful basis

Run every scraping project through these questions before you start:

1. Does the data identify a living person, either directly (name, email) or indirectly (profile ID, IP, photo)? If no, GDPR doesn't apply, so go ahead (while still respecting ToS, robots.txt, and copyright). If yes, keep going.

2. Could that person be an EU or EEA resident? If no, GDPR probably doesn't apply, but check the local laws like CCPA or India's DPDPA. If yes, keep going.

3. Do you have explicit consent from each person? At scraping scale the answer is almost always no, because valid consent is genuinely hard to get this way. If yes, you've got your lawful basis. If no, keep going.

4. Can you lean on legitimate interests? That means writing down a real business need and weighing it against people's privacy rights. Sensitive data like biometrics or health usually can't ride on legitimate interests at all. If the balance comes out in your favor and you can defend it on paper, you can proceed, as long as you also have a way to notify people (see the next step).

5. Can you actually tell the people whose data you collected? Because you didn't get it from them directly, Article 14 generally says you have to tell them who you are, what you're doing with their data, and what rights they have, usually within a month. Cost and hassle aren't a valid excuse, which is the whole Bisnode lesson. If you can't notify people and don't fit a narrow exemption, rethink the project.

6. If none of those work out, don't scrape that data. Grab a non-personal subset instead, or go ask the source for permission.

   
   

A practical compliance checklist

Run through this before any scrape:

• I've sorted every field into personal or non-personal, and I'm only grabbing what I actually need.

• If there's personal data involved, I've picked and documented a lawful basis (consent, or a written legitimate-interests assessment).

• If I collected personal data from somewhere other than the person, I have a plan to notify them (Article 14) within a month.

• I've checked whether the people involved are EU or EEA residents and whether GDPR applies.

• I'm not scraping behind a login, and I've read the site's robots.txt and terms.

• I have a retention plan, and it runs on automated deletion or anonymization scripts rather than someone remembering to clean up. I can also handle access and erasure requests.

• I'm not hammering the site's servers, and my storage is locked down against unauthorized access.

• My scraping setup is walled off from my analytics and production storage (separate containers or buckets, say), so raw scraped data and any personal info in it can't leak into production before it's been cleaned.

  
  

Is web scraping legal beyond GDPR?

GDPR covers personal data in the EU, but it's just one layer. The rules below are mostly US law, though copyright and terms of service apply pretty much everywhere, and they come into play if you, your servers, or your scraping targets touch the US. Even a spotless GDPR setup can run into them. For the fuller picture, see our deeper guide on the legality of web scraping.

Public data and the CFAA (US federal law). US courts have said repeatedly that scraping publicly accessible sites doesn't break the Computer Fraud and Abuse Act, since a bot asking for a public page is no different from a browser doing the same. That protection vanishes the second you cross a login wall.

Terms of service (contract law, applies broadly). Browsewrap terms, the kind hidden in a footer link, often don't hold up, as in Nguyen v. Barnes & Noble. But clickwrap terms you actively agree to at login are enforceable contracts, which is one more reason logged-in scraping is risky.

Copyright (applies broadly). Plain facts like prices, specs, and stock levels can't be copyrighted. Creative content like article text, photos, and original product descriptions usually can be. A crawler can't tell the difference, so check the source first and pull the facts, not the creative wrapper around them.

Trespass to chattels (US state law). If your crawl rate is heavy enough to genuinely strain a site's servers, that can support a claim. Rate-limit and spread out the load.

Trade-secret misappropriation (US). A 2025 ruling out of the US 11th Circuit found that scraping a public site can still count as trade-secret misappropriation if you do it in bad faith, like ignoring robots.txt, beating rate limits, or using deception. So "it was public" isn't a complete defense everywhere anymore.

Behind a login (every regime). Scraping non-public data without permission is the fastest route to trouble, whether that's account suspension, civil suits, or criminal exposure depending on where you are. If you need data behind a login, ask the source for access and get your IPs whitelisted.

Other countries. GDPR has company. California's CCPA and CPRA and India's DPDPA all have their own personal-data rules. The safe default everywhere is the same: scrape public, non-personal data, respect the technical boundaries, and keep records of your compliance work.

Compliance is a habit, not a one-time check

GDPR compliance in scraping isn't something you handle once and forget. It keeps moving. There are lawful-basis assessments to write up, Article 14 notices to send, retention windows to enforce, data-subject requests to answer, and cleaning steps to maintain, and all of it has to keep working across millions of pages while sites change their structure and your selectors break underneath you. The legal line itself is knowable, as this guide hopefully shows. The hard part is running all of it reliably, at scale, without personal data sneaking into your analytics.

That's the real argument for not going it alone. A managed data-as-a-service provider takes both problems off your plate: the engineering grind of keeping high-volume scrapers alive through constant site changes, and the discipline of handing you clean, sanitized, non-personal data that's safe to actually use. You get the data you need for price intelligence, market research, and AI projects without having to build a legal and infrastructure team around it.

That's what we do at Datahut. We handle the scraping, the upkeep, and the data hygiene, so your team ends up with compliant, analytics-ready data and nothing to worry about.

Contact Datahut today!

Frequently asked questions

1. Is scraping personal data a GDPR violation?

Not by itself, but it does bring GDPR into play. The second you scrape data that identifies a living person (a name, email, profile, even an IP address), you become a data controller and need a lawful basis to process it. The violation is scraping that data without a lawful basis, or without respecting transparency and people's rights. The fact that it was publicly visible doesn't get you off the hook.

2. Do I need consent to scrape data under GDPR?

Usually, not consent specifically, but you do need some lawful basis if personal data is involved. Consent is one of six lawful bases, and it's the toughest to get right at scraping scale, since it has to be freely given, specific, informed, and unambiguous. Most compliant scraping of personal data leans on legitimate interests instead, which means documenting a real need and weighing it against people's privacy. If you're only collecting non-personal data, you don't need a lawful basis at all.

3. Does GDPR apply to scraping non-EU websites?

It can. GDPR follows the person, not the server. If a non-EU site holds personal data about EU or EEA residents and you process it, GDPR reaches you even if both you and the site are outside Europe. The Clearview AI fines against a US company are proof of that. On the flip side, if the data is non-personal, GDPR doesn't apply no matter where the site lives.

4. What happens if I scrape personal data without complying with the GDPR?

Regulators can fine you up to €20 million or 4% of your global annual turnover, whichever is bigger, and order you to stop processing and delete the data. Clearview AI alone got hit with €30.5 million from the Dutch DPA and roughly €100 million across the EU for scraping public photos without a lawful basis. And the fines aren't the end of it: you're also looking at cease-and-desist letters, civil claims, and reputational damage. For personal data, it's rarely worth the gamble.

5. Can I scrape LinkedIn or social media profiles under GDPR?

This is risky ground. US courts (hiQ v. LinkedIn) found that scraping public LinkedIn profiles isn't CFAA "hacking," but that's a US access-law point, not GDPR clearance. Profiles are personal data, so GDPR still wants a lawful basis, transparency, and respect for people's rights. Face photos add a biometric layer with an even higher bar. And profiles behind a login are off-limits without permission. If you do scrape public social data, document your lawful basis and steer clear of anything authenticated.

6. What's the safest type of data to scrape under GDPR?

Public, non-personal data: product prices, specs, stock levels, business listings, aggregated market stats. None of it identifies a person, so GDPR simply doesn't apply. That's why e-commerce and price monitoring are the lowest-risk uses of scraping out there. Keep to non-personal fields, respect robots.txt and rate limits, skip the copyrighted content, and you'll stay comfortably on the right side of the rules