Chrome Do Not Track — Developer Guide (2026)

Last updated: April 17, 2026

Google Chrome’s Do Not Track (DNT) setting is a browser privacy feature that sends a signal to websites requesting they not track your browsing behavior. While conceptually simple, understanding how it works, and its limitations, is essential for developers building privacy-conscious applications and users who want greater control over their digital footprint.

DNT was first proposed in 2009 and implemented across major browsers by 2012. The idea was straightforward: give users a way to signal their privacy preferences without requiring them to understand cookies, pixels, or tracking scripts. In practice, the story became far more complicated, and the gap between what users expect from DNT and what it actually delivers is one of the clearest examples of how voluntary technical standards can fail without enforcement mechanisms.

Enabling Do Not Track in Chrome

To enable Do Not Track in Chrome, navigate to Settings > Privacy and security and toggle “Send a Do Not Track request” on. You can also access this directly by typing chrome://settings/privacy in the address bar.

When enabled, Chrome appends the DNT: 1 header to every HTTP request:

DNT: 1

This header tells websites you prefer not to be tracked across sessions. However, the critical word here is “prefer”, the feature relies entirely on websites honoring the request.

Chrome also displays a disclaimer when you enable the setting: “Most websites and web services, including Google’s, don’t alter their behavior when they receive a Do Not Track request.” This is an unusually honest acknowledgment from a browser vendor, and it accurately describes the current state of DNT adoption.

How Chrome Implements Do Not Track

Chrome sends the DNT header with every top-level navigation and resource request. Here’s what happens under the hood:

Request Modification: Before sending any request, Chrome checks if DNT is enabled
Header Injection: If enabled, the DNT: 1 header is added to the request
Server-Side Response: The receiving server reads the header and decides whether to comply

You can verify Chrome is sending the header by checking network requests in DevTools:

Open DevTools (F12 or Cmd+Option+I)
Go to the Network tab
Click any request
Look for DNT: 1 in the Request Headers section

To see this in action, navigate to any site, open DevTools before the page loads, and check the request headers on the initial document request. The DNT: 1 header will appear alongside Accept, Accept-Language, and other standard headers. It is not special-cased or hidden; it is just another HTTP header that the server may or may not read.

The Tracking Protection API Context

Starting with Chrome 120, Google introduced a new Privacy Sandbox API called the Tracking Protection API, which is separate from DNT but serves a related purpose. Unlike DNT, the Tracking Protection API has technical enforcement through third-party cookie restrictions. Understanding this distinction matters for developers: DNT is a voluntary signal carried in a header, while the Privacy Sandbox represents Google’s attempt to enforce privacy constraints at the browser level rather than relying on server-side compliance.

For Developers: Detecting and Respecting DNT

As a web developer, you should check for the DNT header and honor user preferences. Here’s how to handle DNT requests server-side:

Node.js/Express Example

app.get('/api/data', (req, res) => {
 const dntHeader = req.get('DNT');
 if (dntHeader === '1') {
 // User has requested not to be tracked
 // Disable analytics and tracking cookies
 res.cookie('tracking_id', '', { expires: new Date(0) });
 return res.json({
 tracking: false,
 data: getAnonymousData()
 });
 }
 // Normal tracking behavior
 res.json({
 tracking: true,
 data: getPersonalizedData(req.user)
 });
});

This pattern works for API endpoints, but a complete implementation needs to handle it at the middleware level rather than route by route. Wrapping the DNT check in middleware means you apply consistent behavior across your entire application:

// Express middleware for DNT compliance
function dntMiddleware(req, res, next) {
 req.dntEnabled = req.get('DNT') === '1';
 if (req.dntEnabled) {
 // Prevent analytics scripts from being injected server-side
 res.locals.analyticsEnabled = false;
 res.locals.personalizedAds = false;
 } else {
 res.locals.analyticsEnabled = true;
 res.locals.personalizedAds = true;
 }
 next();
}
app.use(dntMiddleware);

Python/Flask Example

@app.route('/api/content')
def get_content():
 dnt = request.headers.get('DNT')
 if dnt == '1':
 # Respect user's DNT preference
 return jsonify({
 'tracking': False,
 'content': get_generic_content()
 })
 # Allow personalized tracking
 return jsonify({
 'tracking': True,
 'content': get_personalized_content(request.cookies)
 })

For Django, the equivalent check is request.META.get('HTTP_DNT'). Django follows the convention of prefixing all HTTP headers with HTTP_ and converting hyphens to underscores in the META dictionary.

Django view example
def my_view(request):
 dnt_enabled = request.META.get('HTTP_DNT') == '1'
 context = {
 'analytics_enabled': not dnt_enabled,
 'personalization_enabled': not dnt_enabled,
 }
 return render(request, 'template.html', context)

JavaScript Client-Side Detection

function respectDNT() {
 // Check if browser has DNT enabled
 const dnt = navigator.doNotTrack ||
 window.doNotTrack ||
 navigator.msDoNotTrack;
 return dnt === '1' || dnt === 'yes';
}
if (respectDNT()) {
 // Disable analytics
 window['ga-disable-UA-XXXXX-Y'] = true;
}

The multiple property checks (navigator.doNotTrack, window.doNotTrack, navigator.msDoNotTrack) reflect the fragmented way browsers implemented the client-side DNT API. Chrome and Firefox use navigator.doNotTrack, older Internet Explorer versions used navigator.msDoNotTrack, and window.doNotTrack was an early non-standard alternative. For broad compatibility, checking all three is the right approach.

Note that client-side detection has a timing issue: by the time your JavaScript runs, analytics scripts may have already fired. For reliable DNT compliance, combine server-side header checking (which can prevent analytics scripts from being included in the page at all) with client-side detection as a secondary check.

// More complete client-side implementation
function initializeAnalytics() {
 if (respectDNT()) {
 console.log('DNT enabled: analytics disabled');
 return;
 }
 // Load analytics only when DNT is not set
 loadGoogleAnalytics();
 loadHotjar();
 initializeMixpanel();
}
// Run before any analytics scripts execute
document.addEventListener('DOMContentLoaded', initializeAnalytics);

The Limitations of Do Not Track

Understanding DNT’s limitations is crucial for both users and developers:

Voluntary Compliance

No law requires websites to honor DNT requests. Major trackers like Google, Facebook, and advertising networks largely ignore the signal. Some explicitly set DNT: 0 when they detect the header, essentially opting out of honoring the user’s preference.

The advertising industry briefly attempted self-regulation through the Digital Advertising Alliance’s opt-out system, but this was separate from the HTTP DNT header and required users to opt out from each ad network individually. The W3C’s DNT working group, which was trying to define a binding standard, suspended its work in 2019 after failing to reach consensus. The core disagreement was whether “tracking” should include first-party analytics, which advertisers refused to exclude.

Limited Scope

DNT only affects HTTP headers. It does not prevent:

Server logs and IP address collection
Browser fingerprinting through Canvas or WebGL
First-party analytics
Cookies set for functional purposes
Session replay tools that record mouse movements and keystrokes
Hashed email matching between first-party databases and ad networks

This scope limitation means a user who enables DNT and believes they are protected from tracking is likely to be disappointed. The header only addresses the narrow case where a website is willing to reduce cross-site tracking in response to an explicit user signal.

No Enforcement Mechanism

There’s no technical way to force a website to honor DNT. Unlike GDPR’s cookie consent requirements or CCPA’s opt-out mechanisms, DNT relies entirely on the honor system.

GDPR and CCPA represent a different philosophy: instead of relying on a voluntary technical signal, they impose legal obligations with financial penalties. The California Privacy Rights Act (CPRA) introduced the concept of Global Privacy Control (GPC), which is a browser signal similar to DNT but with legal weight in California. Websites operating under CPRA must honor GPC as a valid opt-out of data sale. If you are building a privacy-compliant application serving California users, implementing GPC support is more practically important than DNT support.

Fingerprinting Countereffect

Enabling DNT can actually make you more identifiable. Studies show that users with DNT enabled have distinct browser fingerprints, making them easier to track through Canvas and WebGL fingerprinting techniques.

Browser fingerprinting builds a profile from dozens of signals: screen resolution, installed fonts, WebGL renderer information, audio context characteristics, timezone, and language settings. Users who enable DNT form a smaller, more distinctive subset of the browser population, which paradoxically makes them easier to identify. This is an example of the privacy-through-uniformity principle: the less your browser configuration differs from the baseline, the harder it is to fingerprint.

Global Privacy Control: The Successor to DNT

GPC is worth understanding as the practical successor to DNT for developers building privacy-compliant applications. The browser signal is similar, a header called Sec-GPC: 1, but it carries legal weight in several jurisdictions.

// Server-side GPC detection (Node.js)
app.use((req, res, next) => {
 const gpcEnabled = req.get('Sec-GPC') === '1';
 const dntEnabled = req.get('DNT') === '1';
 // GPC has legal weight in California; DNT does not
 req.userOptedOut = gpcEnabled || dntEnabled;
 next();
});

Brave and Firefox both send GPC by default. Chrome does not. If your application serves significant traffic from California, British Columbia, or Colorado (all of which have privacy laws that may recognize GPC), implementing GPC handling is higher priority than DNT.

Practical Alternatives for Privacy

For users who need stronger privacy guarantees, consider these complementary approaches:

Browser Extensions

Extensions like uBlock Origin block known trackers at the network level. Unlike DNT, which asks trackers not to track you, uBlock Origin prevents tracking requests from completing at all. The difference is significant: uBlock Origin’s network-level blocking is technically enforced, while DNT’s compliance is voluntary.

uBlock Origin uses community-maintained filter lists (EasyList, EasyPrivacy, uBlock filters) that are updated frequently to block new tracking domains. You can also add custom rules to block specific domains or URL patterns that appear in your network traffic.

Browser Configuration

Use Firefox or Brave, which block trackers by default:

Brave's shielding blocks trackers automatically
Navigate to brave://settings/shields

Firefox’s Enhanced Tracking Protection (ETP) blocks social media trackers, cross-site tracking cookies, fingerprinting scripts, and cryptomining scripts by default in its Standard mode. The Strict mode adds additional protections including blocking all third-party cookies. Both modes provide substantially stronger protection than DNT alone.

Developer Tools for Testing Privacy

For developers testing privacy features, use Chrome’s privacy sandbox settings:

// Test DNT handling in different scenarios
const testScenarios = [
 { dnt: '1', expected: 'no-tracking' },
 { dnt: '0', expected: 'tracking-allowed' },
 { dnt: null, expected: 'default-behavior' }
];
// Simulate DNT headers in test requests
async function testDNTHandling(scenario) {
 const response = await fetch('/api/data', {
 headers: {
 'DNT': scenario.dnt !== null ? String(scenario.dnt) : undefined
 }
 });
 const data = await response.json();
 console.assert(
 data.tracking === (scenario.expected === 'tracking-allowed'),
 `DNT scenario ${scenario.dnt}: expected ${scenario.expected}`
 );
}

You can also use Chrome DevTools to override request headers when testing:

Open DevTools, go to the Network tab
Right-click a request and select “Edit and Resend” (in some DevTools versions)
Add or modify the DNT header to test your server-side handling

For automated testing, tools like Playwright and Puppeteer let you set custom headers on all requests:

// Playwright: set DNT header for all requests
const browser = await chromium.launch();
const context = await browser.newContext({
 extraHTTPHeaders: {
 'DNT': '1'
 }
});
const page = await context.newPage();
await page.goto('https://your-app.com');
// Verify analytics are not loading

Best Practices for Developers

When building applications, follow these guidelines:

Always check for DNT: Add DNT detection to your analytics and tracking code
Implement GPC alongside DNT: GPC has legal weight that DNT does not; support both signals with the same handler
Provide clear notice: Tell users how you handle their data when DNT is detected
Default to privacy: If you’re unsure, err on the side of not tracking
Document your approach: Include your DNT handling policy in your privacy documentation
Test thoroughly: Verify your DNT implementation across different browsers and settings
Audit third-party scripts: Even if your first-party code respects DNT, embedded third-party scripts (ad pixels, chat widgets, customer data platforms) may not, review each one

Conclusion

Chrome’s Do Not Track feature remains a useful signal for privacy-conscious web development, but it should be part of a broader privacy strategy rather than a standalone solution. For users, combining DNT with tracker blockers and privacy-focused browsers provides stronger protection. For developers, honoring DNT requests demonstrates respect for user privacy and builds trust.

The rise of GPC as a legally enforceable signal represents the most important near-term development in this space. Developers building applications that collect user data should implement GPC handling now, before it becomes a compliance requirement in additional jurisdictions. DNT support is still worth implementing, it is low-cost and signals good intent, but GPC is where the legal and technical momentum currently sits.

Remember that true privacy requires multiple layers of protection. DNT is a helpful starting point, but understanding its limitations helps you make informed decisions about your browsing habits and development practices.

Try it: Estimate your monthly spend with our Cost Calculator.

I'm a solo developer in Vietnam. 50K Chrome extension users. $500K+ on Upwork. 5 Claude Max subscriptions running agent fleets in parallel. These are my actual CLAUDE.md templates, orchestration configs, and prompts. Not a course. Not theory. The files I copy into every project before I write a line of code. **[See what's inside →](https://zovo.one/lifetime?utm_source=ccg&utm_medium=cta-default&utm_campaign=chrome-do-not-track)** $99 once. Free forever. 47/500 founding spots left.