How it works

Your browser clock vs your exit address

6 min read

A site asked you for an extra verification code, or put a challenge in front of a page that never had one, and nothing about your traffic looked unusual. The check that flagged you fits in one line of JavaScript, and it never looks at your protocol.

Your exit address resolves to one country. Your operating system, speaking through the browser, reports another. A tunnel moves packets; it does not touch the second half of that sentence. That contradiction is a more stable signal than the address itself.

What a page reads before you click anything

Four values are available to any script on any page, with no permission prompt and no visible dialog:

  • Intl.DateTimeFormat().resolvedOptions().timeZone — the resolved IANA identifier, such as Europe/Berlin. This is the specific one: it names a region, not a number.
  • new Date().getTimezoneOffset() — the current UTC offset in minutes. Coarser, and it shifts with daylight saving time.
  • navigator.languages and navigator.language — language preferences from the browser or inherited from the OS.
  • The Accept-Language header — the same preference, attached to every HTTP request, before any script runs.
Keep the offset and the named zone apart. UTC+1 identifies no city — Berlin, Oslo, Lagos and Algiers can all sit there. Europe/Berlin is a claim about a place, and it carries that place's daylight saving history.

Collecting this is close to free: synchronous, a few dozen bytes, no consent flow — unlike the Geolocation API, which must ask. The language half has been thinning on purpose. Safari has long reported only the single most preferred language, and Chrome 139 (stable in August 2025) cut the Accept-Language header to one preferred language as well, explicitly to reduce passive fingerprinting, with the same reduction staged for navigator.languages. The time zone got no such treatment: mainstream browsers still hand over the full IANA name by default.

A mismatch means two sources disagree

IP geolocation is a database lookup, not a measurement. Providers build those databases from registry allocations, routing data, ISP-published hints and latency probes. Country is the strong field — MaxMind publishes roughly 99.8% accuracy at country level. City is much softer: the same provider estimates around 66% for US addresses within 50 km of the correct city.

So when the two disagree, the accurate reading is not "your IP is wrong" and not "you have been caught." It is: a database maps this address to country A, while the operating system reports a zone belonging to country B. Neither is a measurement of where you are.

One input to a score, not a verdict

Anti-fraud platforms expose this as a field — usually a boolean along the lines of timezone mismatch — feeding a weighted score alongside device signals, account history and payment data. Vendors are candid that it must not be used alone: honest users produce the mismatch constantly — travelers who never change the laptop's zone, expats, cross-border commuters, remote workers on a machine imaged in the head office's zone.

Because it is weighted rather than decisive, the consequences are graded:

  • Step-up verification at sign-in — a code by email or SMS on a device that was never asked before.
  • Payment review: an extra authentication step on a card transaction, or a manual hold.
  • Challenges appearing more often and taking more attempts to clear.
  • Lower trust on new-account and password-reset flows, where there is no history to offset the signal.

Check it yourself in five seconds

  1. 1Open your browser's developer tools and switch to the Console tab.
  2. 2Paste the one-liner below and press Enter.
  3. 3Read the zone value — that is what every page you visit already sees.
  4. 4Compare it with the country your exit address reports — countries only; the city field is not reliable enough to argue with.

({zone: Intl.DateTimeFormat().resolvedOptions().timeZone, offsetHours: -new Date().getTimezoneOffset()/60, languages: navigator.languages})

If the console reports UTC and you are not in Iceland or Ghana, you likely have a fingerprint-resistance mode on. Firefox's privacy.resistFingerprinting reports UTC whenever it is on — deliberate, and with a compatibility cost.

Why "just change the OS time zone" is a poor trade

The system time zone is not a display preference — every time-aware thing on the machine reads it. Change it and calendar entries shift, meeting invites render at hours nobody agreed to, alarms fire early, and log timestamps stop lining up with your colleagues'. You have traded a scoring signal you may never notice for daily errors you will.

One nuance, widely misstated: authenticator codes derive from absolute time, so changing the named zone alone does not break them. What breaks them is setting the clock by hand, which desynchronizes the machine from real time. If you change anything, change the zone, never the clock.

There is also a population argument against inventing a zone. Firefox's UTC value is defensible because a whole population shares it, and a crowd is what makes any of them anonymous. An extension that picks a "plausible" zone does the opposite: it produces a combination almost nobody else has, on a machine whose GPU string and fonts did not change. Anti-detect browsers and spoofing extensions make you rarer, not commoner — the reverse of the goal.

The neighbors in the same family

Time zone and locale are the cheapest members of a larger set of passively readable properties. The rest describe the machine, not the network path.

  • Canvas: identical drawing instructions produce different pixels across GPU, driver and font-stack combinations.
  • WebGL: vendor and renderer strings plus shader precision. Safari returns constant values, Firefox rounds, Chromium returns the exact GPU string.
  • Screen metrics: resolution, available area, device pixel ratio, color depth.
  • Installed fonts, inferred from how text lays out, with no permission.
  • Audio: small floating-point differences in an offline audio graph.

Changing your exit address moves none of them. That is why "they detect VPNs somehow" feels mysterious: the detection is not looking at the tunnel. It compares what the network says with what the machine says, and notices that only one of the two changed.

The cheap, honest fix

Stop concealing the contradiction and stop producing it. Choose an exit region consistent with the locale you actually use — same country as your system time zone and language settings — and the signal simply does not exist. Nothing is spoofed, nothing breaks, your calendar keeps working.

Apple's Private Relay works on the same principle. Its default keeps the relay address in your general area; the more private setting widens that to your country and time zone only. Neither moves you to another country; that would manufacture the mismatch for you.

  • Prefer an exit in the country whose time zone your OS reports, unless you have a concrete reason not to.
  • Keep one exit region per account instead of hopping between countries mid-session — sudden movement is its own signal.
  • Keep browser language settings and OS locale in agreement; one country's languages with another's zone is a contradiction by itself.

Does a time zone mismatch mean the site knows I am using a VPN?

No. It means two sources disagree about which country you are in. A tunnel is one explanation; travel, an expat setup or a corporate proxy are others. Systems that take the signal seriously weigh it with device history and account age.

Can a website read my time zone without asking permission?

Yes. The IANA zone, the UTC offset and the language preferences are readable by any script with no prompt. The permission dialog you are thinking of belongs to the Geolocation API, which returns actual coordinates.

Is the UTC offset the same thing as the time zone?

No. An offset like UTC+1 is shared by many countries and shifts with daylight saving. The IANA name, such as Europe/Berlin, identifies a specific region and its rules, which is why detection code reads it instead of the offset.

Will changing my system time zone stop the extra verification?

It removes one input from the score, but touches nothing else — canvas, WebGL, fonts and screen metrics are unchanged — and it costs you correct times in calendars, invites and alarms. Right as a one-time correction after moving; a bad trade as routine.

Does a private or incognito window help?

Only partly. It clears cookies and site storage, but the reported time zone, locale, screen metrics and GPU strings are identical. Chrome's incognito mode trims the language list, but does nothing about the zone.

Want the answer for your own connection rather than the general case? The leak test shows what a site sees about you right now — address, WebRTC, time zone and fingerprint — and runs entirely in your browser.

Did this help?

Nothing follows from the answer; only we see it.

Send this to someone

Useful to anyone with the same problem.