Google Is Using Your IP Address for Ads: What Changed

From August 3, 2026 Google uses IP addresses to identify devices for ad measurement and personalization in the EEA, UK, and Switzerland. What changed, why there is no opt-out yet, and which mitigations actually work.

By Tudor Uzun

Founder and Senior Software Engineer, IP Trackers

Published August 4, 2026Editorial standards

On August 3, 2026, Google began using IP addresses to measure and personalize advertising for users in the European Economic Area, the United Kingdom, and Switzerland. Google already received your IP address on every request, because that is how the internet delivers a response to the right machine. What changed is the permitted purpose: an address that was previously used for routing, fraud prevention, and coarse geographic targeting can now be used to identify your device for ad measurement and personalization. There is no dedicated Google opt-out control at launch.

What actually changed on August 3, 2026

It is easy to misread this as Google suddenly collecting something it did not have. That is not what happened. Every web request you make carries a source IP address, and it has to, because the server needs somewhere to send the reply. Google has always seen it. The change is narrower and, in a legal sense, more significant: the set of purposes that address may be used for has expanded.

The bottom three rows are the change. Identifying a device across sessions is what turns an address from a delivery detail into an identifier. Once an IP can be used to recognize the same device returning later, it behaves like a cookie that you cannot clear, did not install, and largely cannot control from inside the browser.

Who this applies to

The announcement is scoped to jurisdictions where an IP address is legally treated as personal data, which is precisely why an announcement was required at all.

The asymmetry in that table is worth sitting with. European users got a formal notice, a consent framework update, and a promise of future controls because the law compelled it. Users elsewhere received no equivalent notice, and the absence of an announcement is not evidence that equivalent processing is not happening. If anything, the countries with the weakest identifier laws are the ones where an announcement would never have been necessary in the first place.

Why this is happening now

This change did not arrive out of nowhere. It is the predictable result of a decade-long project to remove the third-party cookie, and it illustrates a pattern worth recognizing: when one identifier is removed, the industry does not stop identifying people. It moves to the next available signal.

Third-party cookies were the backbone of cross-site advertising for twenty years. Safari restricted them in 2017, Firefox followed in 2019, and Chrome announced its own deprecation and then repeatedly delayed it. Throughout that period the replacement was supposed to be the Privacy Sandbox: a set of browser APIs designed to deliver relevance and measurement without per-user identifiers.

The Sandbox never fully displaced what it replaced. Advertisers reported weaker measurement, publishers reported lower yield, and the deprecation timeline kept moving. What filled the gap instead was a return to signals that were always present but previously off-limits by convention rather than by technical necessity. First-party data, server-side tagging, email-based identity graphs, and now the IP address itself.

The irony is precise. The stated goal of removing third-party cookies was to reduce cross-site tracking. A cookie is at least visible in your browser, listed in settings, and deletable in one click. An IP address is none of those things. Trading one for the other is not obviously a privacy improvement, and it is why the change has drawn the reaction it has.

Measurement and personalization are not the same thing

Google's language covers two activities that get collapsed into one in most coverage. They have different privacy profiles and it is worth separating them.

Measurementanswers questions like "how many distinct devices saw this campaign" and "did the device that saw the ad later visit the advertiser". It is fundamentally about counting and deduplication. Without a device identifier, the same person looks like several people, and a campaign that reached 10,000 devices might be reported as reaching 40,000. Advertisers will not pay reliably against numbers like that, so measurement is the commercial pressure driving this.

Personalization answers a different question: which specific ad should this device be shown. That requires building a profile of inferred interests and attaching it to something stable enough to recognize later.

Measurement is the weaker intrusion of the two, and multi-party computation is genuinely well suited to it, because aggregate counts can be computed without any single party holding the raw inputs. Personalization is harder to defend on the same grounds, because targeting an individual device requires that the device be distinguishable in the first place. Both are covered by the August change, and the announcement does not offer separate controls for them.

Why an IP address counts as a device identifier

A residential IP address is stickier than most people assume. Many broadband connections hold the same address for weeks. Even where the ISP rotates it, the rotation is usually within a small pool belonging to the same regional segment, so the address still narrows you to a household, a neighbourhood, and a provider. Combine that with a browser fingerprint and the pair becomes far more stable than either signal on its own.

You can see exactly how much your own address gives away right now. The homepage IP checker shows the public address a site receives from you, along with the provider and network behind it. To understand which company that address is registered to, read what your ISP is and how to confirm it, and to see how the routing layer describes your connection, run an ASN lookup.

The reason regulators treat this as personal data is that the address does not need to name you to identify you. It needs only to distinguish you reliably from other people, repeatedly, over time. That is the definition of an identifier, and it is why the shift from routing to recognition is a legal event rather than a technical one.

How IP-based identification works in practice

An IP address on its own is a blunt instrument. What makes it powerful is combination. Identity resolution in advertising generally runs along two tracks, and understanding which one applies changes how worried you should be.

Deterministic matching uses a signal that is unique by construction: a logged-in account, a hashed email, a mobile advertising ID. If two events carry the same value, they are the same person, with no inference required. This is the strongest form and it is unaffected by anything in this article.

Probabilistic matching combines several weak signals until the combination becomes distinctive. An IP address, a user agent string, a screen resolution, a timezone, a language preference, and a rough visit pattern are each individually common. Together they are frequently unique, and stable enough to recognize the same device days later. IP address is the strongest single component in that mix, because it is the only one the browser cannot alter or withhold.

There is a third pattern worth naming: the household graph. Because a residential IP is usually shared by everyone in one home, events from a phone, a laptop, a tablet, and a television can be linked into a single unit. This is how cross-device attribution works in practice, and it is why the ad you saw on a work laptop can follow you to a television in the same house. It also means the profile attached to your address is not really yours; it is your household's, blended.

For a broader treatment of how much can be inferred from an address alone, see what someone can actually do with your IP. The short version is that the address rarely reveals who you are directly, and reliably reveals that you are the same visitor as before, which is exactly what advertising requires.

What Google says it is doing technically

Google describes the processing as running through three privacy technologies: on-device processing, Trusted Execution Environments, and secure multi-party computation. Those are real mitigations rather than marketing, and it is worth understanding what each one does and does not promise.

• On-device processing keeps some computation on your hardware, so a raw signal does not always leave the device. It limits what is transmitted; it does not limit what is inferred.
• Trusted Execution Environments run code inside an isolated hardware enclave, so the operator running the server is supposed to be unable to read the data being processed inside it. You are trusting the hardware vendor and the attestation, not a policy document.
• Secure multi-party computation lets several parties compute a joint result without any of them holding the full input. It is genuinely strong for aggregate measurement, and genuinely irrelevant to whether your device was identified in the first place.

None of these change the underlying fact that the address is received and used to recognize a device. They constrain who can see the raw value along the way. That is a meaningful improvement over the alternative, and it is not the same thing as the address not being used.

The consent framework detail that decides whether it happens to you

Google registered this processing under the IAB Transparency and Consent Framework as Feature 3, described as "identify devices based on information transmitted automatically". Google's vendor entry in that framework is ID 755.

The distinction between a Feature and a Purpose in that framework matters more than it sounds. Purposes require their own consent. Features do not independently require consent, but they must be disclosed in the consent interface and must have at least one valid legal basis through an associated Purpose. In practice this means the consent you give or refuse on an individual website is what gates the processing, and the framework entry is what makes it visible.

The chain looks like this. A publisher shows a consent banner. Their consent management platform records your answer and encodes it into a TCF string. That string travels with the ad request to Google. If the string reflects valid consent covering Feature 3, the processing is permitted. If it does not, or if the platform was never updated to surface Feature 3 correctly, Google has said processing limitations apply.

The practical consequence for you is unusual and worth stating plainly: your most effective control is the consent banner on each individual site, not any setting inside your Google account. The banner most people dismiss reflexively is the actual legal gate.

Is there an opt-out?

Not a dedicated one, and not at launch. Google has pointed users toward existing ad personalization controls in My Ad Center while saying a specific control will arrive later in the rollout. No confirmed date has been published.

That leaves a gap. Between August 3, 2026 and whenever a dedicated control ships, a user in a covered region whose publisher captured valid consent is subject to IP-based device identification with no Google-level switch to turn it off. The remaining levers are the consent banner and the network itself.

There is a related thread worth tracking. A real-time bidding privacy settlement dated March 26, 2026 requires IP addresses to be stripped from bid requests for users who opt out. That is a different mechanism covering a different part of the ad stack, and the two should not be confused, but it is a signal that IP-level controls are being built somewhere in the pipeline.

How to tell whether it is happening to you

There is no indicator light for this. Nothing in the browser announces that an ad request carried a consent string permitting device identification. But you can reason about your own exposure from three observable facts.

• Are you in a covered region? If your public address geolocates to the EEA, the UK, or Switzerland, the announced change applies to you. Check with IP location lookup. Note that this follows the address, not your citizenship, so a European traveller on a US address sits outside the announcement and a US traveller in Berlin sits inside it.
• Did you accept the banner? If you clicked accept on a site that monetizes with Google advertising, the consent string almost certainly permitted it. Most consent platforms let you reopen your choices from a footer link.
• Is your address stable? Check the homepage checker today and again in a few days. If the address is unchanged, it is a durable identifier for you specifically. If it rotates frequently, the signal is weaker, though the network prefix usually still identifies your subscription.

A useful diagnostic habit: if you see advertising that reflects activity from a different device in your home, you are observing household-level linkage in action. That linkage does not require you to be signed in anywhere.

What regulators have said

The change has not passed without official attention. Ahead of the launch date, the UK Information Commissioner's Office issued guidance directed at publishers regarding consent obligations, which reflects where the regulatory burden actually falls. Google registered the processing in the consent framework; the publisher is the party who must obtain and record valid consent from the visitor.

This division is deliberate and it has a practical consequence for readers. If you believe consent was not properly obtained, the party answerable in the first instance is usually the website that showed you the banner, not Google. For site owners the same fact is less comfortable, because it means a consent platform that shipped its update late creates exposure for the publisher rather than for the ad network.

Expect this area to keep moving. A processing purpose that launches without a user-facing opt-out, in jurisdictions that treat the identifier as personal data, is the kind of arrangement that attracts follow-up. Nothing in this article should be read as settled law.

What you can actually do, ranked by effect

Most advice published in the last few weeks has been a list of every privacy setting anyone could think of, presented as though the items were equivalent. They are not. Here is what each one actually changes with respect to this specific processing.

Two entries in that table tend to surprise people. Private browsing does nothing at all here, because an incognito window sends exactly the same IP address as a normal one. And encrypted DNS, which is genuinely useful against ISP-level snooping, is close to irrelevant against this particular change, because it hides which names you look up rather than which address you arrive from.

Step one: measure what is currently visible

Before changing anything, establish a baseline. You cannot tell whether a mitigation worked if you never recorded the starting state.

• Open the homepage IP checker and write down the address, the provider, and the ASN.
• Check how precisely that address resolves geographically with IP location lookup. For most home connections the result lands on a city or a regional hub rather than a street.
• Confirm whether your connection already looks like a proxy or VPN to a detection service using proxy and VPN detection.
• Note whether you are being served over IPv4 or IPv6. The homepage shows this, and it changes the advice later in this guide.

If the location result looks wrong, that is normal and does not mean you are protected. Geolocation databases map infrastructure rather than addresses, so a result that is 40 kilometres off still identifies your device perfectly well. Accuracy of location and strength of identification are separate properties.

Step two: Google account settings

Sign in to My Ad Center and turn off ad personalization. Be clear about what this achieves. It stops personalization being applied against your Google identity. It does not stop Google receiving the IP address, and it is not the dedicated IP control that has been promised for later.

While you are there, review activity controls for Web and App Activity, YouTube history, and location history. These are separate systems from the change described here, but they feed the same profile, and there is limited value in hardening the network layer while leaving a fully populated account history in place.

Step three: stop dismissing consent banners

This is the highest-leverage habit change in the entire guide, and it is free. Under the framework described above, the publisher's consent string is what authorizes the processing. Clicking "accept all" to clear a banner is the moment the permission is granted.

Choose "reject all" or "necessary only" where the banner offers it. Where it does not, open the preferences panel and disable the advertising purposes individually. It takes a few extra seconds per site and it is the only control that operates on the actual legal basis rather than downstream of it.

Step four: change the address itself

If the identifier is your IP address, then replacing your IP address with someone else's is the direct countermeasure. A VPN routes your traffic through a provider server so the address a site receives belongs to the provider rather than your household.

This breaks the specific link that the August change depends on. It is the strongest single action available to an individual user right now, which is why nearly every article about this change ends up recommending it. Compare options on our ranked best VPNs page, or if you are not ready to pay, review the tradeoffs in best free VPNs first, because free tiers carry real costs that are easy to miss.

Whatever you choose, verify it rather than trusting the connect button. Run the VPN verification workflow and confirm the visible address actually changed. A surprising number of clients report a connected state while traffic continues to exit through the original interface, which is exactly the failure described in VPN connected but IP not changing.

What a VPN does not fix

The honest version of this advice includes the limits. A VPN addresses one signal well and leaves several others completely intact.

The row that undoes most people is the second one. If you tunnel your traffic and remain signed in to a Google account, you have changed the network identifier while leaving the strongest identifier in place. An account is a stable, unique, self-declared identity. No amount of address rotation competes with it.

The last two rows are why verification matters. A tunnel that leaks WebRTC or IPv6 hands over the original address while presenting a changed one in the obvious place. Check both with the WebRTC leak test and the IPv6 leak test, and check DNS separately with the DNS leak test.

Router-level versus device-level protection

Where you apply a VPN changes what it covers, and the difference matters more here than it does for most privacy advice, because the identifier in question is attached to the connection rather than to the browser.

A device-level client protects the machine it runs on. It is easy to install, easy to toggle per network, and it leaves every other device in the house presenting the original address. Given that household graphs link devices by shared address, protecting one laptop while the television, the console, and three phones continue to present the home address achieves considerably less than it appears to.

A router-level configurationtunnels every device behind it, including hardware that cannot run VPN software at all: smart televisions, streaming sticks, consoles, and the growing category of appliances that talk to the internet without a meaningful settings screen. The tradeoffs are real. Throughput is limited by the router's processor, per-device exceptions require configuration, and a misconfiguration fails silently for the whole household rather than for one machine.

For this specific change, router-level is the better architectural fit, because it makes the household present one consistent non-residential address rather than a mixture. If you go that route, verify from several devices rather than one, using the homepage checker on each. Finding that the television still exits through the original interface is common and entirely defeats the purpose.

Mobile is a different problem

Everything above assumes a browser on a home connection. Mobile changes several assumptions at once, and generally not in your favour.

Mobile carriers assign addresses from large shared pools, usually behind carrier-grade NAT, and those addresses rotate as you move between cell sites. That makes the IP a weaker and noisier identifier than a fixed home address. On its own this would be good news for privacy.

It is offset by the fact that mobile apps do not depend on the IP the way a browser does. An app can read a resettable advertising identifier provided by the operating system, which is a deterministic signal far stronger than any probabilistic combination. Google's announcement describes collecting addresses through customer tags, SDKs, and HTTP calls, and the SDK path is the mobile one.

The practical implication is that on mobile you should spend your effort on the advertising identifier rather than the address. On Android, reset the advertising ID and consider deleting it entirely where the option exists; on iOS, decline app tracking requests. A mobile VPN still helps for browser traffic and still breaks the household link when you are on home Wi-Fi, but it does not touch the identifier that mobile advertising actually prefers.

IPv6: the part nobody mentions

If your connection is IPv6, the identification story is different and generally worse. IPv4 scarcity forced providers to share addresses between customers, which accidentally created a privacy benefit. IPv6 has no scarcity, so your devices can each hold a globally unique address, and older address-generation schemes derived the interface portion from the hardware MAC address, producing an identifier that followed the device between networks.

Modern operating systems default to privacy extensions that randomize and rotate that portion, which substantially helps. It is worth confirming rather than assuming, because the network prefix still identifies your subscription even when the interface portion rotates. The background is in IPv4 vs IPv6, and you can confirm what is actually exposed with the IPv6 leak test.

CGNAT: when your address is not only yours

A large share of mobile and fixed-wireless subscribers, and a growing share of fibre customers, sit behind carrier-grade NAT. Hundreds or thousands of households share one public IPv4 address, and the carrier distinguishes them by port range internally.

For IP-based identification this cuts both ways. A shared address is a weaker identifier, because the same value maps to many households, so the signal is diluted. But it also means ad measurement attributed to "your" address includes strangers' behaviour, and reputation problems earned by anyone in that pool land on you. If you are unsure which applies to you, run the CGNAT test and read the CGNAT IP address range guide.

The practical takeaway is that CGNAT is not a privacy strategy. It is an address-conservation measure that happens to blur one signal, and it can be removed by your provider at any time without notice.

If you run a website: what you are now responsible for

Publishers carry the compliance burden here, not Google. Under the EU User Consent Policy, the obligations that apply from August 3 include:

• Displaying accurate disclosures covering Google's processing of IP addresses for device identification.
• Providing a prominent link to Google's Help Center page explaining how IP addresses are used.
• Confirming your consent management platform surfaces Feature 3 within Google's vendor entry, ID 755.
• Verifying your TCF string correctly reflects Feature 3. Platforms that were not updated may emit non-compliant strings, which Google has said will result in processing limitations.

If you monetize with AdSense or Ad Manager and serve European traffic, the single most useful thing you can do this week is open your consent management platform's vendor list and confirm Feature 3 appears under vendor 755. A platform that has not shipped the update leaves you exposed on the disclosure requirement while also degrading your own ad performance.

There is a revenue dimension that publishers should think through honestly rather than optimistically. Better device identification improves measurement, and better measurement usually raises what advertisers will pay for European inventory, which has been discounted for years precisely because it was harder to measure. That is the upside, and it is real.

The offsetting risk is that the compliance obligation sits with you while the processing decision sat with someone else. If a consent flow is later judged inadequate, the publisher is the party that displayed it. Treat the Help Center link and the Feature 3 disclosure as non-optional rather than as a checkbox, keep a dated record of your consent platform configuration, and be able to show what your banner looked like on any given day. That record costs nothing to keep now and is impossible to reconstruct later.

One further note for site owners running their own analytics: this change concerns Google's advertising products, but it is a useful prompt to audit every third party that receives your visitors' IP addresses. Most sites have more of them than the owner remembers, because each one arrived with a tag, an embed, or a font.

If you are outside Europe

You received no notice, you have no consent banner gating the processing, and you have no promised control. That is not a reassuring position, and it should not be read as one. The announcement exists because European law required it; the absence of an announcement elsewhere reflects the absence of a legal trigger rather than the absence of the practice.

The mitigations that operate at the network layer work identically regardless of jurisdiction. Changing the address a site receives does not depend on a regulator. If you are in a country without identifier protections, the network layer is a larger share of your available options than it is for a European reader, simply because you have fewer of the other kinds.

A fifteen-minute audit you can run today

1. Record your current public address, provider, and ASN from the homepage checker.
2. Note whether the connection is IPv4 or IPv6, and whether a CGNAT test says the address is shared.
3. Turn off ad personalization in My Ad Center and review activity controls.
4. Connect your VPN, then re-check the homepage. The address, provider, and ASN should all be different. If any of them did not change, stop and fix that before continuing.
5. Run the DNS, WebRTC, and IPv6 leak tests in that order.
6. Set a habit: reject non-essential cookies on consent banners rather than accepting defaults.

A worked example: one household, before and after

Consider a household in Dublin with a fibre connection, a static-in- practice IPv4 address, four people, and roughly a dozen connected devices. Nobody in the house has changed a setting.

Before August 3. Every device presents the same public address. Google receives it on every ad request and uses it to route the response, to filter obvious fraud, and to decide that ads should be in English and relevant to Ireland. Cross-device linking happens through signed-in accounts where they exist, and not otherwise. A teenager browsing while signed out is, from an advertising perspective, a largely unlinked stream of events.

After August 3.The same address may now be used to recognize devices for measurement and personalization, subject to the consent captured on each publisher. The signed-out teenager's browsing can be associated with the same household unit as everyone else's. A product researched on one person's laptop can inform what a different person sees on the television. None of this requires an account, and none of it is visible in any browser setting.

After a router-level VPN.All twelve devices present one address belonging to a VPN provider, shared with that provider's other subscribers. The household link still exists, but it now points at a pool rather than at a home, and it no longer geolocates to Dublin. Signed-in activity remains fully linked, because the account was never the thing being changed.

That last sentence is the honest summary of the entire mitigation story. You can make the network layer stop identifying your household. You cannot make an account stop identifying its owner.

What to watch next

Three things are worth tracking over the coming months.

• The promised opt-out. Google has committed to a dedicated control without confirming a date. Whether it arrives, and whether it genuinely prevents the processing rather than only the personalization layer, is the single most important open question.
• Regulatory response. Launching a new processing purpose with no user-facing control, in jurisdictions that classify the identifier as personal data, is likely to attract scrutiny. Any finding would reshape the practical advice above.
• Geographic expansion. The covered regions were determined by law rather than by preference. There is no technical reason the same processing could not run elsewhere, and in most of the world no announcement would be required for it to begin.

Common mistakes

• Assuming incognito helps. Private browsing does not change your IP address by even one bit.
• Trusting the VPN connect indicator.Verify with an external check rather than the client's own status.
• Tunnelling while signed in. An account identifier overrides a network identifier every time.
• Believing wrong geolocation means safety. An address that resolves to the wrong city still identifies the same device consistently.
• Treating encrypted DNS as an answer here. Valuable generally, close to irrelevant against this specific change.
• Waiting for the opt-out. No date has been confirmed, and the processing began on August 3.

Frequently asked questions

Did Google start collecting my IP address on August 3, 2026?

No. Google has always received your IP address, because every internet request carries one and a server cannot reply without it. What changed is the set of purposes it may be used for, which now includes identifying your device for ad measurement and personalization in the covered regions.

Does this mean Google is reading my Gmail for ads?

No, and this is the most common misreading circulating. The announcement concerns advertising platform integrations, specifically AdSense and Ad Manager and the associated buying platforms. Gmail, Search, and YouTube are not named in this initiative. Treat claims that they are as unverified.

Can I opt out?

There is no dedicated opt-out control at launch. Google has said one will arrive later in the rollout without confirming a date. In the meantime the effective controls are refusing consent on individual sites and changing the address you present at the network layer.

Does a VPN stop it?

A VPN breaks this specific signal, because the address Google receives becomes the provider's rather than yours. It does not stop cookies, account-based identification, browser fingerprinting, or history-based personalization, so treat it as one strong layer rather than a complete answer.

Am I affected if I am not in Europe?

The announcement covers the EEA, the UK, and Switzerland because those jurisdictions treat IP addresses as personal data. No equivalent announcement was made elsewhere, which reflects the absence of a legal requirement to make one rather than a guarantee that the processing does not occur.

I share an IP with my whole building. Does that protect me?

Partially, and not deliberately. A shared address under carrier-grade NAT is a weaker identifier because it maps to many households. It also means activity and reputation from strangers is attributed alongside yours, and your provider can move you to a dedicated address at any time.

Related reading

For the mechanics behind the signals discussed here, see What Is My ISP?, Why Is My IP Location Wrong?, What Can Someone Do With My IP?, and How to Hide My IP. For the broader picture of stepping away from Google services, read Goodbye to Google Privacy.