The Topics API tried to replace cross-site identifiers
For years, online advertising relied on third-party cookies to recognize a browser across unrelated websites. The Topics API proposed a different trade: let the browser infer a few broad interests locally, then disclose a limited selection to eligible advertising callers.
That proposal is now being retired. Chrome's current status page lists Topics among the Privacy Sandbox technologies scheduled for deprecation and removal. Understanding what it attempted—and why it did not last—is useful far beyond advertising. Browser privacy depends as much on adoption, governance, and incentives as it does on clever code.
How the Topics API was designed to work
The browser grouped recent activity into categories from a public taxonomy. A visit might contribute to a broad interest such as travel, fitness, or books. The system did not hand an advertiser a list of exact URLs or the complete browsing history.
According to Google's Topics API technical overview, the browser calculated a small set of leading topics during an epoch, set to one week by default. A caller could receive at most one topic from each of the three recent epochs—and only if that caller had previously observed the relevant topic for that user.
A small percentage of returned topics were selected randomly from the taxonomy. That noise was intended to make the signal less deterministic. The values were also broad, temporary, and computed on-device rather than created as a central dossier of visited pages.
What a participating site could learn
A caller could request topics through JavaScript or HTTP headers. The response used numeric identifiers tied to a taxonomy and model version. In ordinary language, an advertising service might learn that the browser had recently shown an interest in a category—not which article produced the classification.
That is a narrower signal than an unrestricted cross-site cookie. It is not the same as no signal. Interests can still influence what a person sees, and repeated observations can join a broader profile. The W3C Technical Architecture Group's design discussion raised concerns about fingerprinting and the possibility that inferred topics could be used to make sensitive or discriminatory assumptions.
This cumulative risk resembles the issue described in how websites fingerprint browsers without cookies. Each attribute may look harmless in isolation. The combination can become more revealing.
Why Chrome is retiring the Topics API
Google announced that Chrome would maintain its existing approach to third-party-cookie choice rather than complete the long-planned phaseout. That changed the role of the advertising APIs designed around a cookie-free future.
In its update on Privacy Sandbox technologies, Google cited low adoption and ecosystem feedback when deciding to retire Topics and several related systems. The official Privacy Sandbox feature status, updated in August 2026, places Topics in the “deprecate and remove” group for both Chrome and Android.
Deprecation is a process, not one instant switch. Developers need time to remove integrations, feature-detect failures, and avoid breaking pages when calls stop returning data. Documentation may remain online for historical reference even after the underlying implementation disappears.
The privacy lesson is bigger than one API
Topics tried to reduce the detail and longevity of interest signals. That is a worthwhile direction. But a privacy-preserving replacement must also work across browsers, earn trust from users, and give publishers and advertisers enough value to adopt it.
A feature controlled mainly by one browser vendor faces an interoperability problem. Sites cannot build a universal advertising system around a signal that other major engines do not share. A taxonomy also carries policy choices: which interests exist, which are sensitive, who updates the list, and how errors are corrected.
Browser-side inference does not automatically settle consent questions either. Google's implementation guidance warned that access could require user consent in some jurisdictions, just as cookies do. Moving computation onto the device changes the data flow; it does not erase the social meaning of behavioral advertising.
What users should expect
Most people do not need to change anything. As Chrome phases the API out, participating sites should receive less or no Topics data. Exact timing depends on Chrome's staged deprecation and removal process. The feature was never a universal web standard, and browser support was limited.
The retirement also does not mean third-party cookies vanish. Chrome's choice model leaves their use dependent on browser settings and user decisions. Tracker blocking, storage partitioning, and careful cookie controls therefore remain important. Our guide to browser storage partitioning explains one protection that continues independently of Topics.
Nor does deleting Topics eliminate fingerprinting. Hardware hints, language, screen properties, network behavior, and other signals still matter. The Device Memory API shows why browsers deliberately coarsen even performance-related information.
A practical checklist
- Review third-party-cookie and ad-privacy settings in the browser you actually use.
- Use tracker blocking to reduce requests before they become profiles.
- Do not assume a privacy-branded API is supported by every browser.
- For developers, feature-detect Topics and remove dependencies before Chrome completes the phaseout.
- Prefer contextual advertising when an ad can be chosen from the page's subject without profiling the reader.
The Topics API will be remembered as an ambitious attempt to replace a familiar tracking mechanism with a smaller browser-managed signal. Its retirement is not proof that privacy engineering is futile. It is evidence that web privacy features must survive technical review, market adoption, and public legitimacy at the same time.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.