What Is Doubleclick.net? Google's Ad and Tracking Domain

Doubleclick.net is an advertising domain. Its job is to deliver ads into pages you visit and to measure what happened next: whether the ad loaded, how often you have already seen it, and whether a click led anywhere. Serving and measuring ads requires identifiers, so this is not a passive file host, and answers that treat it as one skip the part you asked about.

The name is older than its owner. DoubleClick was an independent ad-serving company through the 1990s and 2000s, and Google acquired it in 2008. The products were folded into Google's advertising stack and renamed, into what is sold today as Google Ad Manager, Campaign Manager 360, and Display & Video 360. The brand went away and the domain did not, for an unglamorous reason: doubleclick.net hostnames are written as literal strings into publisher ad tags, click-through URLs, video players, and corporate blocklists across a very large number of sites. A name embedded that widely costs more to move than to keep.

Google's own documentation confirms the domain is current rather than legacy. Its page on how Google uses cookies in advertising names doubleclick.net as one of the domains its advertising cookies may be set from, alongside google.com, googlesyndication.com, and googleadservices.com.

So the honest answer runs to two clauses. Doubleclick.net is legitimate infrastructure operated by Google, and it is advertising and measurement infrastructure. Both are true at once, and you can verify the first half yourself in a minute.

Two questions sit behind most searches for this domain: is this really Google, and who told my browser to contact it. A TLS certificate answers the first, because it is issued to a verified domain holder and names the operator of the host you reached.

The lab behind this article resolves hostnames and reads certificates, nothing else. It sends no HTTP request that could be counted as an ad impression: we are not measuring an ad network by generating traffic for it. Run on 2026-07-29 under Node v24.14.0, all three checks passed. The recorded output, verbatim:

PASS  doubleclick.net resolves to at least one address  (6 address(es), first family IPv4)
PASS  doubleclick.net certificate is issued by Google Trust Services  (issuer O=Google Trust Services, CN=WR2, subject CN=*.doubleclick.net)
PASS  stats.g.doubleclick.net presents a Google-issued certificate  (issuer O=Google Trust Services, SAN sample=DNS:*.g.doubleclick.net, DNS:*.invitemedia.com)

checks passed: 3/3

Read what that settles. The issuing organization is Google Trust Services, Google's own certificate authority, and the subject covers *.doubleclick.net. That rules out a whole category of worry: not a lookalike, not a hijacked name, not something malware registered to blend into a log. It rules out nothing about what the domain does.

One detail in the third line is a fossil. The certificate served by stats.g.doubleclick.net carries *.invitemedia.com among its subject alternative names, a domain from an advertising company Google acquired after DoubleClick. Certificates keep that kind of history, which is why they beat a brand name as evidence.

Reproduce the certificate half without our script:

openssl s_client -connect doubleclick.net:443 -servername doubleclick.net </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject

Then answer the second question in your browser. Open developer tools, select the network panel, filter for doubleclick, and reload. The Initiator column names the script that made the request, turning "why is this on my machine" into "this page's ad tag asked for it".

Nobody types doubleclick.net into an address bar. You reach it because a page you opened instructed your browser to, before you clicked anything.

When a publisher sells space on a page, they place an ad tag in it: markup or JavaScript that runs while the page renders and asks an ad server to fill the slot. Google's publisher tag documentation tells publishers to load its library from https://securepubads.g.doubleclick.net/tag/js/gpt.js, so one documented copy-paste makes every visitor's browser contact the domain. That request goes to a host other than the one in your address bar, which makes it a third-party request your browser sends automatically. A single news article can touch dozens of third-party hosts this way.

The subdomain tells you which part of the machinery you caught.

• securepubads.g.doubleclick.net: the publisher-side tag library that finds the ad slots on a page and requests fills for them.
• googleads.g.doubleclick.net: the ad request and the creative that comes back, the fetch that produces what you actually see.
• stats.g.doubleclick.net: measurement and reporting traffic rather than visible creative. It shows up on pages counting something, including pages with embedded media and no visible banner.
• ad.doubleclick.net: the long-serving delivery and click-redirect host, which is why some links travel through it toward an advertiser's page.

That explains why it turns up in the browser status bar, developer tools, router logs, DNS query logs, and website data on a phone, all of them normal. On an iPhone, an entry under Safari's website data records pages you loaded. Nothing was installed to produce it, which answers the usual fear that seeing the name means something got in.

The popular answers split into two camps, each wrong by half: one says it is spyware you should delete, the other says it is just Google, ignore it.

It is not malware. The check above names the operator and shows a certificate issued by that operator's own authority for this exact name. It is also not software on your computer: there is nothing to uninstall, and an antivirus scan will never find it, because a domain is not a file. Advice to delete doubleclick.net is really advice to delete a cookie or a history row, records of pages you loaded rather than a program that runs. Cleanup tools that flag a doubleclick cookie are applying a tracking-cookie category, not detecting code.

And it is advertising and measurement infrastructure, so tracking here is not an accusation, it is the function. Calling that harmless is as inaccurate as calling it a virus. Whether you want it running is a preference to act on deliberately, not a security incident.

A third risk is real, separate, and routinely confused with the other two. Ad slots accept creatives from many buyers, and ad networks have repeatedly been abused to deliver malicious or deceptive ones, an attack called malvertising. That risk lives in the ad supply chain rather than in the domain being counterfeit, and it is the strongest practical argument for a content blocker even if personalized advertising does not bother you.

The case that does deserve alarm is a hostname that merely contains the string. Anything ending in doubleclick.net is the real domain. A registration that only borrows the word, or buries doubleclick inside an unfamiliar domain, is not, and the certificate check settles it in one command.

Ad delivery is not one action. It is four, and each leaves a different trace.

Selection comes first: a page has a slot, a request goes out describing the context, something gets chosen. Recognition comes second, and it is the part readers care about. A cookie set on the ad domain, or a mobile advertising ID inside an app, lets the ad system recognize the same browser on a different site later. MDN's third-party cookie reference describes the mechanism: a cookie whose domain and scheme differ from the page you are looking at, readable again on every other page that loads that same third-party domain.

The other two are on Google's advertising cookies page linked earlier: capping, described there as stopping you from seeing the same ad over and over again, and measuring the effectiveness of ads, along with detecting and stopping click fraud. That page also documents Google's personalization and data practices, which change over time and belong at the source rather than restated here.

One diagnostic falls out of that. Browsers do not treat third-party cookies alike, which is why two people comparing notes disagree about whether they are tracked. Per MDN, Firefox enables Total Cookie Protection by default and Safari applies its tracking prevention policy by default; Chrome does not block them except in Incognito or when you set it to. WebKit is blunter: Intelligent Tracking Prevention "by default blocks all third-party cookies. There are no exceptions to this blocking." What every host observes regardless of cookie policy is connection metadata: the address a request came from and the user agent that sent it, which the what-is-my-IP diagnostic shows directly.

The most valuable thing here is not a fact about one domain, it is the ability to classify the next one. Two Google domains out of the same log make that concrete, and our guide to gstatic.com reaches a genuinely different conclusion about its subject, because the two do different jobs.

Four questions classify almost any unfamiliar hostname. Read the registered domain first, the rightmost labels rather than the left edge, because everything to the left is chosen by whoever controls the registration: googleads.g.doubleclick.net ends in doubleclick.net and is that domain, while doubleclick.net.example-cdn.tld ends somewhere else entirely. Read the certificate second, issuer organization and subject, with the command earlier in this guide. Read the subdomain third, since these names are usually literal: fonts, stats, ads, pubads. Then ask what the domain is for, because purpose predicts behavior: an asset host has no reason to set cookies, an ad host has every reason to.

The same reading settles the connectivity-check hostnames that fill router logs, such as captive.apple.com, which look alarming and are not. It also warns you about blocklists: Google names googlesyndication.com and googleadservices.com in that same official list, so blocking doubleclick.net alone leaves plenty of advertising traffic running.

Start by naming what you want, because two levers get confused. Turning off ad personalization changes which ads you see. Blocking requests changes whether the ad code runs at all. Picking the wrong one is why people conclude nothing works.

A browser content blocker is the most precise tool if the requests are what you object to. It stops the request before it is made and can be switched off per site when something breaks. Its cost is social rather than technical: some publishers detect blocking and ask you to disable it or subscribe, which is their decision about their own pages, so the honest options are comply or read elsewhere.

Third-party cookie settings target recognition rather than delivery: pages still render and ads still load, but the cross-site identifier goes, at the cost of sign-in widgets, embedded comment systems, and some checkout flows that use it.

My Ad Center changes something different: it turns personalized ads on or off and manages the activity that feeds them. That changes which ads you get, not whether ads are served, and a setting tied to a signed-in account does not follow you to a browser you are not signed in to. Right tool for targeting, wrong tool for the traffic.

DNS-level blocking, with Pi-hole, NextDNS, or a hosts file, covers every device on the network including apps that ignore browser settings. It is also the bluntest, because the symptom depends on what your resolver answers: an NXDOMAIN reply surfaces as ERR_NAME_NOT_RESOLVED, while a sinkhole pointing at 0.0.0.0 surfaces as ERR_CONNECTION_REFUSED. The consequence nobody warns you about is click redirects: links routed through an ad server toward their destination, common in newsletters, land nowhere when that host is unreachable, and get reported as a broken link on a site that works perfectly.

On iPhone and iPad the same two levers are Safari's cross-site tracking prevention, the ITP mechanism above, and a content blocker from the App Store.

Two situations are not yours to configure. On a work, school, or other managed network, ad and tracker filtering is the administrator's policy, and questions belong with them. If a site declines to serve you while a blocker runs, that refusal is the site's choice about its own content: accept it, or go elsewhere.