Web Scraping · Last updated: July 2026
Is Web Scraping Illegal in India? Laws, Risks, and Practical Guidance
Web scraping is not automatically legal or illegal in India. India does not have one law that gives the same answer for every scraping project.
The legal risk depends on how the website is accessed, what information is collected, whether personal or copyrighted material is involved, what contractual restrictions apply, and how the extracted data will be used.

Why the answer depends on the project
“Web scraping” describes a technical process. It does not describe one fixed set of facts.
For example, these projects raise different questions:
- Collecting publicly displayed product prices for internal analysis
- Copying complete product descriptions and photographs
- Extracting personal contact information from profiles
- Using an official API under its licence
- Collecting information after signing in to an account
- Circumventing a paywall or another access restriction
- Republishing or selling an extracted database
A useful review separates five issues:
- Access: How does the system reach the information?
- Data: What exact fields and content are collected?
- Rights: Does the material involve personal data, copyright, confidentiality, or contractual restrictions?
- Conduct: Does collection bypass controls or interfere with the website?
- Use: Will the data be analysed internally, republished, profiled, licensed, or sold?
Public visibility is relevant, but it does not resolve all five questions.

Does India specifically prohibit web scraping?
India does not have a single statute dedicated exclusively to web scraping.
Depending on the project, the relevant legal areas may include:
- The Information Technology Act, 2000
- The Digital Personal Data Protection Act, 2023
- The Copyright Act, 1957
- Contract law and website terms
- Confidentiality obligations
- Sector-specific laws and regulations
The correct starting point is therefore not simply, “Is scraping legal?”
It is: What will the system access, collect, retain, and do with the information?
The Information Technology Act and access without permission
Section 43 of the Information Technology Act applies to specified conduct performed without permission of the owner or person in charge of a computer resource. Its listed acts include accessing a computer resource and downloading, copying, or extracting data or information. Whether it applies to a particular scraping workflow depends on the facts and should be assessed by qualified counsel.
Section 66 applies when a person dishonestly or fraudulently performs an act referred to in section 43. This added mental-state requirement matters: section 66 does not state that every automated request or extraction is automatically a criminal offence.
Access methods that need closer review:
- Visiting a public page without signing in
- Using an official API under agreed terms
- Scraping after accepting account terms
- Accessing subscription-only material
- Using revoked credentials
- Circumventing a login or paywall
- Continuing after technical blocking or a formal objection
- Accessing a non-public partner portal
Obtain legal advice before proceeding when a project involves credentials, restricted content, technical circumvention, revoked access, or continued collection after an objection. Changing proxies, accounts, browsers, or automation tools does not itself resolve an authorisation issue.
The DPDP Act and scraped personal data
The Digital Personal Data Protection Act, 2023 addresses digital personal-data processing. Its provisions do not all commence on the same date.
| Date | DPDP development |
|---|---|
| August 11, 2023 | The Act was enacted |
| November 13, 2025 | Sections 2, 18–26, 35–43 and specified portions of section 44 commenced |
| November 13, 2026 | Certain additional provisions are scheduled to commence |
| May 13, 2027 | Sections 3–17 and other listed provisions are scheduled to commence |
The May 13, 2027 date follows from the official provision that those sections commence 18 months after November 13, 2025. Because this article is being prepared in July 2026, it must not imply that all substantive processing obligations under sections 3–17 are already operational.

What about personal data that is publicly available?
Section 3 contains an exclusion for personal data made or caused to be made publicly available by the individual to whom the data relates, or by a person who is legally required to make it public. That wording does not support the broader claim that all personal data visible online is freely available for any collection or use.
Relevant questions include:
- Who made the information public?
- Was the page genuinely public or accessible only through an account?
- What information will be combined with it?
- Will it be used to contact, profile, rank, or make decisions about individuals?
- Will it be republished or sold?
- Do copyright, contract, confidentiality, or sector-specific requirements also apply?
- Which DPDP provisions were in force on the project date?
Section 3 itself is among the provisions scheduled for May 13, 2027. Its future application should therefore be discussed separately from the legal position in July 2026.
Personal-data fields requiring careful review:
- Personal phone numbers, email addresses, and home addresses
- Individual employment histories and social-media profiles
- Location information and government or account identifiers
- Financial or health information and children's data
- Data used to profile individuals
The fact that information appears on a webpage does not, by itself, determine whether the planned collection and use are appropriate.
Does public access make scraping legal?
Public access is one factor, not a complete legal conclusion.
Collecting a limited set of factual product fields for internal analysis presents different issues from copying full descriptions, photographs, reviews, and seller profiles for republication.
Even when a page is public, review:
- Whether the material contains facts or protected expression
- Whether website terms address automated collection
- Whether personal data is involved
- Whether collection affects the source system
- Whether the source has objected
- Whether the information will be republished or sold
- Whether an official API is available
Permission to view a page should not automatically be treated as permission to reproduce every element for every purpose. For page discovery versus field extraction, see our data crawling guide.
Copyright and copied website content
Section 14 of the Copyright Act describes copyright as including exclusive rights over specified uses of a work or a substantial part of it. For literary works, those rights include reproduction and electronic storage.
Web scraping can involve both factual data and protected material. The legal analysis may differ depending on what is copied.
Content needing closer review includes:
- Product descriptions, articles, photographs, and reviews
- Original summaries and category descriptions
- Substantial parts of a compiled database
- Original selection or arrangement of material
Extracting a product identifier and listed price is not the same as copying every product description and image.
Internal analysis is different from republication:
- Analysing selected information internally
- Displaying limited facts in a private dashboard
- Republishing complete descriptions or mirroring a catalogue
- Selling copied content or creating a competing database
Section 52 contains specified exceptions, including fair dealing for private or personal use—including research—criticism or review, and reporting current events. The availability of an exception is fact-dependent. A commercial project should not assume that describing its purpose as “research” is sufficient.
Website terms and account-based access
Website terms may address:
- Automated access, copying, commercial use, and republishing
- Account sharing, API use, storage, retention, and access after termination
How those terms were presented and accepted can matter.
Public pages
Some public websites provide terms through a footer link or site notice. Their contractual effect should be assessed in context. Avoid both extremes: assuming every term displayed anywhere is automatically binding, and assuming online terms cannot apply without a handwritten signature.
Account and API terms
Contractual questions become more prominent when a person or organisation creates an account, accepts terms, purchases access, accepts developer conditions, receives credentials under an agreement, or uses an official API.
Automating an account does not remove restrictions that may apply to the account holder. An official API may provide a clearer authorised route, but its licence may still control permitted fields, call limits, storage, retention, attribution, display, redistribution, and termination.
What does robots.txt mean legally?
A robots.txt file communicates crawl preferences to automated agents. It can indicate which paths a website asks compliant crawlers not to visit.
It is not a complete legal licence, contract, or statutory ruling.
A robots.txt rule does not independently determine authorisation, copyright, contract, personal-data obligations, confidentiality, or permitted reuse.
However, ignoring an explicit restriction may become relevant when combined with repeated blocking, excessive request rates, concealment, continued access after an objection, or attempts to reach clearly restricted paths. A project review should document robots.txt, website terms, rate limits, access conditions, and blocking responses separately.
Common scraping scenarios
The table below provides review priorities, not legal conclusions.
| Scenario | Review priority | Questions to resolve |
|---|---|---|
| Public product prices collected moderately for internal comparison | Standard review | Terms, fields, frequency, technical impact, intended use |
| Official API used within its licence | Standard review | Licence scope, retention, display and redistribution |
| Full descriptions and images copied | Higher priority | Copyright, substantial copying and republication |
| Professional profiles and personal contact details collected | Higher priority | Personal data, source, purpose, profiling and outreach |
| Data collected after account terms are accepted | Higher priority | Contract and authorised use |
| Login, paywall or technical control bypassed | Legal review before proceeding | Authorisation, intent and technical conduct |
| Extracted database republished or resold | Higher priority | Copyright, contract, privacy and confidentiality |
| Non-public partner portal accessed | Clear permission required | Contract, confidentiality and authorisation |
| Collection affects website performance | Legal and technical review | Disruption, damage, request controls and notice |
| Collection continues after a formal objection | Legal advice required | Notice, authorisation, contractual and dispute risk |

Questions to answer before starting
Source and access
- Which websites and URL patterns are in scope?
- Are the pages public? Is an account, subscription, or payment required?
- Has anyone accepted terms for the organisation?
- Is an official API available? Has the source previously objected or blocked access?
Data fields
- What exact fields are required? Does the project collect personal data?
- Does it copy descriptions, images, articles, or reviews?
- Can unnecessary fields be excluded?
- Will every record retain its source URL and extraction date?
Collection method
- How frequently will pages be requested?
- Are browser interactions or JavaScript rendering required?
- What request-rate controls will apply?
- How will failed requests and blocking be logged?
- Could the workflow affect the source system?
Intended use
- Is the data for internal analysis, customer display, republication, or resale?
- Will individuals be contacted or profiled?
- Will the information be used for AI training?
- How long will it be retained? Who will receive it?
Governance
- Who approved the project purpose?
- Has legal counsel reviewed the actual scope?
- Who will handle complaints or objections?
- What happens when terms or access controls change?
- When must collection stop for further review?
Need a structured project-scoping checklist before development?
Download the Project ChecklistProject-scoping checklist only—not a legal-compliance certificate.

A hypothetical scoping example
Suppose the initial request is:
Collect every professional profile from a platform, including all contact information.
Before development, the team should establish:
- Whether the pages are public or account-only
- Whether platform terms have been accepted
- Why personal phone numbers and email addresses are needed
- Whether company-level information would be sufficient
- Whether biographies and photographs can be excluded
- Whether the information will be used for outreach, profiling, resale, or internal research
- How long records will be retained and whether an authorised API exists
- Which matters require legal approval
A narrower technical scope might include public company pages, defined business fields, source URLs, a limited retention period, controlled collection frequency, and no personal contact details or copied biographies.
That narrower scope may make a project easier to assess. It does not prove that the project is lawful.
When legal advice should be mandatory
Obtain project-specific Indian legal advice when the proposed workflow involves:
- Login-required or paid content, account or API terms, or circumventing access controls
- Personal data at meaningful scale, children's or sensitive information
- Confidential or leaked material, full copyrighted works, or database resale
- Individual profiling or AI training using copied material or personal data
- A regulated industry, a formal objection from the source, or high-volume collection that could affect operations
- Uncertainty about which statutory provisions are in force
Give the lawyer the real technical specification. “We plan to scrape public data” is not enough information for a useful assessment.
Technical scoping does not replace legal review
A technical team can define and document the project so that it is easier to evaluate. Useful controls include:
- Limiting collection to approved domains and paths
- Defining exact fields and excluding unnecessary personal or protected content
- Using official APIs where appropriate
- Applying controlled request rates and retaining source URLs and timestamps
- Logging errors, blocks, and retries; setting retention limits
- Restricting access to the resulting data and stopping when an unresolved legal issue arises
These measures may reduce operational uncertainty and create an auditable record. They do not guarantee legal compliance.
How Nenodata can support the technical scope
Nenodata currently lists Enterprise Web Scraping and Enterprise Web Crawling among its services. Its site describes defining data requirements, extracting and structuring selected fields, and delivering results through APIs, webhooks, or files.
For a legally sensitive project, Nenodata's relevant role is to help document technical requirements such as target sources, access conditions, required fields, collection frequency, output format, validation rules, logging, delivery, and retention requirements.
Nenodata should not be presented as providing legal clearance. The customer and its legal advisers must decide whether the proposed collection and use are appropriate.
Learn more about enterprise web scraping, enterprise web crawling, how Nenodata works, and our enterprise-grade web scraping guide.
Final answer
Web scraping is not automatically illegal in India, but publicly visible information is not automatically free to collect and reuse without limits.
A project should be reviewed according to its access method, the information collected, applicable terms and restrictions, copyright and personal-data issues, its technical impact, and its intended use.
Define those facts before choosing a scraper or provider. Obtain qualified Indian legal advice when the workflow involves restricted access, personal data, copied content, republication, resale, technical circumvention, or other unresolved legal questions.
Submit the target sources, required fields, access method, estimated volume, refresh frequency, and intended use.
Share the target source, fields, access method, volume, refresh frequency, output format, and intended use. We discuss technical requirements—not legal approval or compliance guarantees.
Discuss Your Data Requirements