---
title: "Browser Timezone Leak Check: Intl, Accept-Language, System Settings"
description: "Websites read your timezone and language with no prompt. Learn the four sources, what sets each value, and how to self-check with console commands and /ip."
url: https://cdnping.org/en/blog/timezone-language-leak-check
language: en
published: 2026-10-24
category: "IP & privacy"
tags: ["browser privacy","timezone","browser language","Accept-Language","browser fingerprint"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# Browser Timezone Leak Check: Intl, Accept-Language, System Settings

A browser timezone leak means a web page's script reads your operating system's timezone setting directly, with no permission prompt, and a proxy does not affect it. Language works the same way: the browser sends an `Accept-Language` header with every request, and scripts can also read `navigator.languages`. So wherever your exit IP moves to, `Asia/Shanghai` and `zh-CN` are still handed to the site as-is.

This article answers one question: where do these values come from, which setting controls each, and how do you check them yourself. The goal is privacy self-checking, so you know what system information a site can still read while you use a proxy. It does not cover disguising your environment to get past any platform's risk controls. Follow each service's terms and your local laws.

If you first want to understand what a mismatch between timezone, language, fonts and IP means, read [Browser fingerprinting and environment checks: what mismatched timezone, language, fonts and IP reveal](/en/blog/browser-environment-consistency). This article is more hands-on: commands and where to find each setting.

## Where do web pages read your timezone and language?

There are four direct sources and one indirect source.

| Source | How it is read | Example value | Needs JavaScript? |
| --- | --- | --- | --- |
| IANA timezone name | `Intl.DateTimeFormat().resolvedOptions().timeZone` | `Asia/Shanghai` | Yes |
| UTC offset | `new Date().getTimezoneOffset()` | `-480` | Yes |
| Language preference list | `navigator.language`, `navigator.languages` | `zh-CN`, `["zh-CN","zh","en"]` | Yes |
| HTTP request header | `Accept-Language` | `zh-CN,zh;q=0.9,en;q=0.8` | No, the server receives it directly |
| Fonts (indirect) | Measuring text width with Canvas or CSS to tell whether a font exists | Whether common Chinese fonts are installed | Yes |

A few easy-to-misread points:

- The sign of `getTimezoneOffset()` is reversed. It returns "UTC minus local time" in minutes, so UTC+8 gives `-480`, not `480`. It gives only an offset, not a region, and many timezones share the same offset.
- The IANA timezone name carries more information. `Asia/Shanghai`, `Asia/Hong_Kong` and `Asia/Taipei` share the same offset, but the names map directly to different regions.
- `Accept-Language` is the only source in the table that does not rely on a script. Turning off JavaScript does not stop it; the server sees it in the very first request. Weights such as `q=0.9` express preference order.
- Fonts are only supporting evidence. Having Chinese fonts installed does not mean the system language is Chinese, since many English-language systems install them too. Their value is in being read together with the other signals.

## How do you read these values on your own computer?

Open any web page, press F12 to open the Console, and paste this:

```js
const r = Intl.DateTimeFormat().resolvedOptions();
console.table({
  timeZone: r.timeZone,
  locale: r.locale,
  offsetMinutes: new Date().getTimezoneOffset(),
  language: navigator.language,
  languages: navigator.languages.join(", "),
  dateString: new Date().toString(),
});
```

The `dateString` row usually includes a localized timezone name, such as "中国标准时间" (China Standard Time) in parentheses, which exposes both the timezone and the system language.

`Accept-Language` has to be checked in the network panel: switch DevTools to Network, reload the page, click the first document request, and find `accept-language` under Request Headers.

## What controls each of these values?

As a rule of thumb, the timezone follows the operating system, while the language source differs by browser.

### Timezone

| Environment | Setting that determines the timezone | Command-line check |
| --- | --- | --- |
| Windows | Settings → Time & language → Date & time; with "Set time zone automatically" on, it consults location services | `tzutil /g` or PowerShell `Get-TimeZone` |
| macOS | System Settings → General → Date & Time; "Set time zone automatically" also relies on location | `readlink /etc/localtime` |
| Linux | `/etc/localtime` or `timedatectl`; the `TZ` environment variable at process start overrides it | `timedatectl`, `echo $TZ` |
| Chrome / Edge | Follows the system; no separate timezone setting | Use the console code above |
| Firefox | Follows the system by default; with `privacy.resistFingerprinting` on, it reports UTC with zero offset instead | Same as above |
| Safari | Follows the system | Same as above |

"Set time zone automatically" makes the timezone follow the device's physical location, not your network exit. So if you carry a laptop on a trip, the timezone may change on its own; if you connect a proxy, the timezone does not move.

On Windows, `tzutil /g` returns Windows' own timezone ID (for example `China Standard Time`). The browser converts it to an IANA name internally, so the two spellings differing is normal.

### Language

| Environment | `navigator.languages` and `Accept-Language` come from | Where to change it |
| --- | --- | --- |
| Chrome / Edge | The browser's own preferred-language list, generated from the system language at first install | Settings → Languages → Preferred languages; drag to reorder |
| Firefox | The browser's own web-page language list | Settings → General → Language → "Choose the languages used to display web pages" |
| Safari | The macOS preferred-language list | System Settings → General → Language & Region |
| Windows system | Settings → Time & language → Language & region → Preferred languages | PowerShell `Get-WinUserLanguageList`, `Get-Culture` |
| macOS system | System Settings → General → Language & Region | `defaults read -g AppleLanguages`, `defaults read -g AppleLocale` |
| Linux | `LANG` and `LC_*` environment variables, plus the desktop environment's locale settings | `locale` |

A common case: you change the preferred language in Chrome but not the system language. `navigator.languages` changes, yet the timezone name, number format and date format in `new Date().toString()` may still follow Chinese conventions. Language signals come from more than one place, and changing one does not change them all.

### Fonts

The font list comes from the font files installed on the machine. On Linux, `fc-list :lang=zh family` shows which Chinese fonts are installed; on Windows they are in `C:\Windows\Fonts`, and on macOS in Font Book. Sites usually do not get the full list; they test a batch of common fonts one by one for presence. For more on how font fingerprinting works, see [What is browser fingerprinting: 20+ features sites use to recognize you without cookies, and how to self-check](/en/blog/browser-fingerprint-explained-self-check).

## Run a full self-check with cdnping /ip

The console only shows the browser side. To compare it with your exit IP, the [IP & environment check](/en/ip) is more convenient. It shows the geolocation of your exit IP (11 geolocation databases vote, with a confidence score) and also checks timezone, language and fonts. The fingerprint is computed locally and not uploaded.

Follow these steps:

1. Open [/en/ip](/en/ip) in your normal setup, without changing any settings. Note the exit IP's country and city, its confidence, and the results for timezone, language and fonts.
2. Check whether the exit IP's location is trustworthy. If the geolocation databases disagree widely, hold off on conclusions; the databases themselves can be wrong. See [Why 11 IP databases give different locations](/en/blog/ip-geolocation-databases-differ).
3. Compare the timezone with the IP's location. If the region implied by the timezone name matches the IP location, they are consistent; if not, a site can tell that "the device is in one place and the network exit is in another."
4. Compare the language list. Look at the first language and how many languages the list holds. The longer the list and the rarer the combination, the easier it is to tell you apart.
5. Look at the mainland China split-routing and multi-exit results on the same page. If sites inside China see a different IP, the problem goes beyond timezone and language. Read [How Chinese websites see your real IP: how mainland split-routing detection works and its three outcomes](/en/blog/how-chinese-sites-see-your-real-ip) and [How split tunneling works](/en/learn/split-tunneling).
6. When you need to share a result, turn on the option to hide the IP before generating the watermarked result image. Do not just screenshot the whole screen.

For how to read each individual check, see [How to read a browser environment check: all 13 items explained](/en/blog/browser-environment-check-explained).

## Is a timezone and IP mismatch always a bad sign?

No. All of these are normal scenarios:

- You are traveling abroad, "Set time zone automatically" is off, and the system is still on your home timezone.
- A company network routes everyone through one overseas exit while employees keep their local timezone.
- A mobile network or corporate leased line has an IP that geolocation databases place in a different city.

From a privacy standpoint, the issue is not the mismatch itself but whether you know what you are exposing. If you use a proxy so that sites cannot tell where you are, your timezone and language still reveal your rough region.

Conversely, changing your timezone and language to match the exit IP is not something this article recommends. It would disrupt everyday use (calendars, file times and page display language would all change), and some services use browser-environment signals in security decisions. The specific rules depend on each platform's terms; follow the terms of service and local laws.

## What are reasonable ways to expose less?

These are measures with little effect on daily use, taken for privacy:

| Approach | Effect | Cost |
| --- | --- | --- |
| Trim the browser language list to the one or two languages you really need | Makes the language list less distinctive | Multilingual fallback may work less well on a few sites |
| Turn off the system's "Set time zone automatically" and set your usual timezone manually | Avoids exposing your movements through timezone changes | You adjust it manually when you travel |
| Enable `privacy.resistFingerprinting` in Firefox | Reports the timezone as UTC with zero offset and reduces the precision of other fingerprint signals | Times on web pages may display incorrectly and some sites may misbehave |
| Use a browser that unifies fingerprints, such as Tor Browser, for sensitive browsing | Many users report identical values | Slow, and some sites block it or ask for frequent verification |
| Check WebRTC and DNS as well | Keeps the IP itself from leaking through other channels | Requires settings in each browser |

The last item usually matters more than the timezone: a timezone reveals only a rough region, while a WebRTC leak can expose your real IP directly. For setup, see [How to turn off WebRTC leaks: Chrome, Firefox and Safari settings](/en/blog/fix-webrtc-leak-chrome-firefox-safari); for the underlying mechanism, see [DNS leaks and WebRTC leaks](/en/learn/dns-leak-webrtc-leak).

Keeping the browser "ordinary" is more useful than making it "random": a patchwork of settings is itself rare and so easier to single out.

## How do developers simulate timezones when testing multilingual sites?

If you are testing the internationalization logic of your own site, you do not need to change system settings. In Chrome DevTools, open the Sensors panel (type "Show Sensors" in the command menu). You can override the timezone ID and locale for the current tab, and closing DevTools restores them. On Linux and macOS you can also start a separate browser instance with an environment variable such as `TZ=America/New_York` for testing.

These methods are for development and debugging only. After testing, return to normal browsing and use [/en/ip](/en/ip) to confirm no settings were left behind.