Cookie Consent in India: Complete DPDP Act Guide for Websites

Yes, cookie consent is mandatory in India under the Digital Personal Data Protection Act, 2023 (DPDP Act). If your website uses cookies that collect or process personal data of individuals in India, you need their consent before those cookies are set.

This is not a gray area. The DPDP Act requires consent for all processing of digital personal data. Cookies that track users, store preferences tied to identifiable individuals, or enable advertising all process personal data. No consent, no cookies.

This guide covers exactly what you need to do: what counts as valid consent, how to implement it correctly, which cookie categories need consent, how to integrate Google Consent Mode v2, and the mistakes that could cost you up to Rs 250 Crore.

Is Cookie Consent Mandatory in India?

Yes. Here is the legal basis.

The DPDP Act applies to the processing of digital personal data of individuals in India. Section 4 establishes that personal data can only be processed for a lawful purpose with the consent of the Data Principal (the individual), unless it falls within specific exemptions.

Cookies that collect or process personal data — such as user identifiers, browsing behavior, device fingerprints, location data, or any data that can directly or indirectly identify an individual — require consent.

Which Cookies Need Consent?

Not all cookies are created equal. Here is how cookie categories map to DPDP requirements:

Cookie Category	Example	Contains Personal Data?	Consent Required?
Strictly Necessary	Session cookies, load balancers, CSRF tokens, authentication cookies	Typically no (functional, not identifying)	No — these are essential for the website to function
Preferences/Functional	Language selection, theme preferences (when tied to user account)	Yes, if tied to identifiable user	Yes
Analytics/Performance	Google Analytics, Hotjar, Mixpanel	Yes — user IDs, IP addresses, behavior	Yes
Advertising/Marketing	Google Ads, Meta Pixel, LinkedIn Insight Tag	Yes — tracking across sites, building profiles	Yes
Social Media	Embedded widgets, share buttons that track	Yes — cross-site tracking	Yes

The key question: Does the cookie collect, store, or transmit data that can identify a specific individual? If yes, consent is required.

Strictly necessary cookies are the exception. Cookies that are essential for the basic functioning of the website — such as maintaining a shopping cart, keeping a user logged in during a session, or protecting against CSRF attacks — generally do not require consent because they do not process personal data for a separate purpose. However, even session cookies can become consent-worthy if they are also used for analytics or tracking.

What Counts as Valid Consent Under the DPDP Act

The DPDP Act sets a high bar for valid consent. Not every cookie banner meets it.

Seven Requirements for Valid Consent

1. Free Consent must not be coerced. You cannot make website access conditional on accepting all cookies (cookie walls). The user must have a genuine choice to reject non-essential cookies and still use your website.

2. Specific Consent must be obtained for each specific purpose. You cannot bundle analytics consent with advertising consent under a single “accept all” button (though you can offer an “accept all” as a convenience alongside granular options).

3. Informed The user must know:

• What personal data is being collected
• For what purpose
• Who will process it (including third parties)
• How long the data will be retained
• How they can withdraw consent

4. Unambiguous Consent requires a clear affirmative action. Scrolling, continuing to browse, or closing a banner does not constitute consent. The user must actively click to accept.

5. Clear and Plain Language The consent notice must be written in language the average person can understand. Legal jargon does not count.

6. Available in Applicable Languages Under the DPDP Act, consent notices should be available in the languages of the Eighth Schedule of the Indian Constitution. At minimum, provide English and Hindi. Ideally, include the primary languages of your user base.

7. Easy to Withdraw Withdrawing consent must be as easy as giving it. If consent was given with one click, it should be withdrawable with one click. A buried settings page requiring multiple steps does not meet this standard.

What Does NOT Count as Consent

Practice	Valid Under DPDP?	Why
Pre-ticked checkboxes	No	Not an affirmative action
”By continuing to browse, you accept cookies”	No	Implied consent is not valid
Cookie walls (“accept or leave”)	No	Not freely given
Bundled consent (“accept all or nothing”) as the only option	No	Not specific or granular
Dark patterns making “reject” harder than “accept”	No	Not freely given, undermines genuine choice
Consent collected once and never refreshed	Risky	Consent should be renewed periodically and when purposes change
No option to withdraw consent after accepting	No	Withdrawal must be as easy as acceptance

How to Implement Cookie Consent: Step by Step

Step 1: Audit Your Cookies

Before you can ask for consent, you need to know what cookies your website sets.

How to audit:

1. Open your website in a private/incognito browser window
2. Open Developer Tools (F12) and go to the Application tab
3. Check Cookies, Local Storage, and Session Storage
4. Navigate through your key pages and note every cookie set
5. For each cookie, document:
   • Name
   • Domain (first-party or third-party)
   • Purpose
   • Expiry duration
   • Whether it processes personal data
   • Category (necessary, analytics, marketing, etc.)

Tools that can help:

• Browser developer tools (free)
• Cookiebot scanner (free for small sites)
• OneTrust cookie scanner
• ZenoComply’s website scanner (identifies all tracking technologies)

Step 2: Categorize Your Cookies

Group each cookie into one of these categories:

Strictly Necessary (No consent needed):

• Session management cookies
• Load balancing cookies
• Security cookies (CSRF tokens)
• Cookie consent preference cookies themselves

Functional/Preferences (Consent needed):

• Language preference cookies tied to user profiles
• UI customization cookies linked to accounts
• Chat widget cookies that store user data

Analytics (Consent needed):

• Google Analytics (_ga, _gid, _gat)
• Hotjar (_hj*)
• Mixpanel cookies
• Any tool tracking user behavior

Marketing/Advertising (Consent needed):

• Google Ads conversion cookies
• Meta/Facebook Pixel (_fbp, _fbc)
• LinkedIn Insight Tag
• Any retargeting or remarketing cookies
• Affiliate tracking cookies

Step 3: Build Your Consent Banner

Your cookie consent mechanism needs these elements:

The initial banner must include:

1. A clear statement that the website uses cookies
2. A brief explanation of each cookie category and its purpose
3. An “Accept All” button
4. A “Reject All” button (equally prominent as Accept All)
5. A “Manage Preferences” or “Customize” option
6. A link to your full Cookie Policy

The preference center (behind “Manage Preferences”) must include:

1. Toggle switches for each cookie category
2. Strictly Necessary cookies always on (non-toggleable), with an explanation of why
3. All other categories defaulting to OFF (opt-in, not opt-out)
4. A list of specific cookies in each category (name, purpose, duration)
5. Third-party information for each category
6. A “Save Preferences” button
7. A “Reject All” button

Design requirements:

• The “Reject All” button must be the same size, color prominence, and position level as “Accept All”
• Do not use dark patterns (e.g., graying out “Reject,” making it a text link while “Accept” is a bright button)
• The banner should not cover the entire page or block access to the website
• Provide a way to re-access the consent preferences at any time (e.g., a persistent cookie icon or a link in the footer)

Step 4: Implement Consent-Based Cookie Loading

This is the technical step most websites get wrong. You must block all non-essential cookies until consent is given.

How it works:

1. When a user first visits your site, only strictly necessary cookies are loaded
2. Analytics scripts, advertising pixels, and marketing tags must NOT fire
3. When the user gives consent for a specific category, only those scripts load
4. If the user rejects a category, those scripts never load
5. If the user withdraws consent later, those scripts must stop and their cookies must be deleted

Implementation approaches:

Option A: Tag Manager with Consent Mode Use Google Tag Manager or a similar tool to gate all tags behind consent signals. Tags only fire when the corresponding consent category is approved.

Option B: Consent Management Platform (CMP) Deploy a CMP that automatically handles script blocking and unblocking based on consent state. The CMP injects scripts only after consent is confirmed.

Option C: Manual Script Management Replace direct script tags with conditional loading logic that checks consent state before injecting scripts into the page. This is the most labor-intensive but gives complete control.

Step 5: Store and Manage Consent Records

The DPDP Act requires you to demonstrate that consent was obtained. Maintain records of:

• Who consented (anonymized identifier, not necessarily the name)
• When consent was given (timestamp)
• What they consented to (which categories)
• How consent was collected (version of the banner/notice)
• Withdrawal history (when consent was withdrawn, for which categories)

Store these records for the duration of the processing and a reasonable period after (at least the limitation period for any claims).

Step 6: Set Up Consent Withdrawal

Users must be able to change their cookie preferences at any time. Implement:

1. A persistent link in the website footer (e.g., “Cookie Preferences” or “Manage Cookies”)
2. Clicking this link reopens the preference center
3. The user can toggle categories on or off
4. On saving changes:
   • For newly rejected categories: stop scripts, delete cookies, and stop future processing
   • For newly accepted categories: load relevant scripts
5. Process withdrawal within 7 days (per DPDP Draft Rules)

Google Consent Mode v2: How It Fits In

Google Consent Mode v2 became mandatory for Google services (Google Ads, Google Analytics) in the EEA in March 2024. While not yet legally required for India specifically by Google, implementing it now is strongly recommended because:

1. It provides the technical infrastructure to respect cookie consent
2. It works with your consent banner to adjust Google tag behavior
3. It is likely to become a Google requirement for India once DPDP enforcement begins
4. It helps maintain measurement capability while respecting consent

What Google Consent Mode v2 Does

Google Consent Mode allows your Google tags to adjust their behavior based on consent status. Instead of simply blocking tags (losing all data), it sends “cookieless pings” that allow Google to model conversions and analytics without setting cookies.

The Two Required Parameters

Parameter	Purpose	Default (before consent)
ad_storage	Controls cookies used for advertising (Google Ads)	denied
analytics_storage	Controls cookies used for analytics (Google Analytics)	denied

Additional Parameters in Consent Mode v2

Parameter	Purpose
ad_user_data	Controls whether user data can be sent to Google for advertising
ad_personalization	Controls whether personalized advertising is allowed
functionality_storage	Controls cookies for enhanced functionality
personalization_storage	Controls cookies for personalization
security_storage	Controls cookies for security purposes

Implementation Steps for Google Consent Mode v2

1. Set default consent state (before user interaction):

Configure all consent parameters to denied by default when the page loads. This ensures no cookies are set before consent is given.

2. Update consent state on user action:

When the user interacts with your consent banner:

• If they accept analytics cookies, update analytics_storage to granted
• If they accept advertising cookies, update ad_storage, ad_user_data, and ad_personalization to granted
• If they reject, the parameters remain denied

3. Persist consent across sessions:

Store the consent state in a first-party cookie so that returning users do not see the banner again (unless consent has expired or you need to recollect).

4. Verify implementation:

• Check Google Tag Assistant to confirm consent signals are being sent
• Verify that in “denied” mode, no advertising or analytics cookies are set
• Confirm that in “granted” mode, cookies are set as expected

Consent Mode v2 Behavior by State

Consent State	Google Analytics	Google Ads	What Happens
All denied	No cookies, sends cookieless pings	No cookies, no conversion tracking	Google models behavior (less accurate)
Analytics granted, ads denied	Analytics cookies set	No ad cookies	Full analytics, modeled ad conversions
All granted	All cookies set	Full conversion tracking	Full measurement
Consent withdrawn	Cookies deleted, reverts to denied	Cookies deleted, reverts to denied	Returns to modeled behavior

Common Cookie Consent Mistakes

Mistake 1: Loading Cookies Before Consent

The problem: Your Google Analytics or Facebook Pixel scripts are in the page HTML and fire on page load, before the cookie banner is even displayed.

The fix: All non-essential scripts must be blocked by default and only loaded after consent is granted. Use a tag manager with consent signals or a CMP that handles script injection.

Mistake 2: No “Reject All” Button

The problem: Your banner offers “Accept All” and “Manage Preferences” but no direct way to reject all non-essential cookies.

The fix: Add a “Reject All” button that is equally prominent to “Accept All.” Three options should be visible: Accept All, Reject All, Manage Preferences.

Mistake 3: Dark Patterns in Banner Design

The problem: The “Accept” button is a bright, large button while “Reject” is a small, gray text link. Or the banner is designed so that the easy path is acceptance.

The fix: Both accept and reject options must be equally visible, equally sized, and equally easy to select. Consistent styling removes any nudging toward acceptance.

Mistake 4: Not Deleting Cookies on Withdrawal

The problem: When a user changes their preferences from “accepted” to “rejected” for a category, the existing cookies remain in their browser.

The fix: On consent withdrawal, actively delete all cookies in the rejected category and stop associated scripts. This must happen immediately, not on the next page load.

Mistake 5: Cookie Wall

The problem: The website cannot be used until the user accepts cookies. The banner covers the entire page with no way to dismiss it without accepting.

The fix: Users must be able to use your website’s core functionality even if they reject all non-essential cookies. The banner should be dismissible, and rejection should not degrade the user experience.

Mistake 6: Ignoring Third-Party Cookies

The problem: You’ve handled your first-party cookies but embedded third-party widgets (chat tools, social media embeds, video players) set their own cookies without consent.

The fix: Third-party embeds must also be gated behind consent. Use placeholder content or lazy-loading that only activates the embed after consent for that category is given.

Mistake 7: No Way to Change Preferences Later

The problem: Once the user makes a choice, they have no way to change their cookie preferences. The banner does not reappear, and there is no settings link.

The fix: Add a persistent link in your footer (or a floating icon) that opens the cookie preference center at any time.

Mistake 8: Collecting Consent but Not Recording It

The problem: You show a cookie banner and collect consent, but you do not store a record of who consented, when, and to what.

The fix: Implement consent logging. Store a timestamped record of each consent decision with the version of your consent notice at that time.

Mistake 9: Not Updating Consent When Cookie Practices Change

The problem: You add a new analytics tool or advertising pixel but do not update your cookie notice or re-collect consent.

The fix: Whenever your cookie categories or specific cookies change, update your cookie notice and consider re-collecting consent from existing users for the new purposes.

Mistake 10: Not Accounting for Indian Languages

The problem: Your cookie banner is only in English, but a significant portion of your Indian user base prefers Hindi or other regional languages.

The fix: Provide your cookie consent notice in at least English and Hindi. Ideally, detect the user’s language preference and serve the banner in their language from the 22 languages in the Eighth Schedule.

Cookie Policy: What to Include

Beyond the banner, you need a comprehensive Cookie Policy page. It should contain:

1. What cookies are — A plain-language explanation
2. How your website uses cookies — List each category with its purpose
3. Specific cookies used — Table with cookie name, provider, purpose, category, and duration
4. Third-party cookies — Who the third parties are and links to their privacy policies
5. How to manage cookies — Reference your cookie preference center
6. How to delete cookies via browser — Brief instructions for major browsers
7. Contact information — Your Data Protection Officer or grievance officer’s details
8. Update history — When the policy was last updated

Compliance Checklist for Cookie Consent in India

Use this checklist to verify your implementation:

• All cookies audited and categorized
• Cookie consent banner displays before any non-essential cookies load
• No cookies set before consent (verified in browser dev tools)
• “Reject All” button is equally prominent to “Accept All”
• Granular consent by category available through “Manage Preferences”
• All non-essential categories default to OFF
• Consent records stored with timestamp, categories, and notice version
• Users can change preferences at any time via persistent link
• Cookie withdrawal deletes existing cookies and stops scripts
• Third-party embeds gated behind consent
• Cookie banner available in English and Hindi (minimum)
• Cookie Policy page is published and linked from the banner
• Google Consent Mode v2 implemented (if using Google services)
• Consent withdrawal processed within 7 days
• No dark patterns in banner design
• Banner does not block website access (no cookie wall)

Frequently Asked Questions

Do Indian government websites need cookie consent? The DPDP Act provides certain exemptions for the State and its instrumentalities. However, government websites that process personal data through cookies should still follow best practices.

What about mobile apps? Do they need cookie consent? Mobile apps typically use SDKs and device identifiers rather than cookies. However, the DPDP Act applies to all processing of digital personal data, regardless of the technology used. If your app processes personal data through SDKs, you need consent for that processing.

How long should consent be valid? The DPDP Act does not specify a consent validity period. Best practice is to refresh consent annually and whenever your cookie categories or purposes change.

Can I use a consent management platform (CMP) built for GDPR? Yes, but you will need to configure it for DPDP requirements: default language support, 7-day withdrawal processing, and ensuring all breach notification timelines are met. Most major CMPs support multi-regulation configurations.

What happens if a user does not interact with the cookie banner? No consent has been given. Only strictly necessary cookies should be active. Non-essential cookies must not load.

Start With a Website Scan

The fastest way to find out if your website’s cookie practices are DPDP-compliant is to scan it. A compliance scan identifies every cookie and tracking technology on your site, checks for consent banners, and flags gaps.

Scan Your Website for Free — Instant results showing every cookie, tracker, and consent gap on your site. Fix issues before enforcement begins.