How Websites Determine Your Location

Why can a German IP open a storefront for India?

Imagine a customer in India opening an online store through a proxy listed as German. In this example, the store also identifies the IP address as German. Yet the country selector at the top of the page still says India, and the catalogue is the one available to customers in India.

On an earlier visit, the customer selected India in that menu. The store saved the choice and uses it again when the customer returns. It has two useful pieces of information: the current request comes from an IP it associates with Germany, and the customer previously asked to shop for India. Keeping the selected market is a deliberate part of this store's behaviour.

The IP's country and the selected storefront therefore answer different questions. One concerns the address from which the request arrived; the other controls the shopping experience. The same distinction applies to a city selected on a weather website or a destination entered into a hotel search. The site can show information for a place without deciding that the visitor is physically there.

What information reaches the website?

The server handling a page request sees the connection's IP address. For a request sent through a proxy, this is the address the proxy uses to connect to the service. IP geolocation data associates that address with a country or area. The site itself or a service handling requests on its behalf can perform that lookup.

The request can also contain language preferences and cookies previously saved for the site. After the page loads, its JavaScript can read further browser settings and request device location through the browser's permission system. Signing in supplies another connection to information: the site can retrieve the account's saved details.

A site uses the information needed for its features. A simple page may rely on the IP address alone, while a store with accounts, regional catalogues and delivery options has reasons to use several sources. There is no requirement for every website to collect every item in the table.

How does a site remember the selected country?

Cookies are small pieces of data that a browser stores and sends with later requests to the relevant site. A cookie can contain a country preference directly. It can also contain an identifier through which the server finds a saved session and its settings. Other browser storage, such as localStorage, can keep preferences for the site's scripts to read.

Changing the proxy changes the connection used for subsequent requests. It does not remove those stored values. In the shopping example, a request from the German IP can carry the same session cookie as before, allowing the store to retrieve the India selection.

Account settings can persist across browsers and devices. A saved home address, delivery address or preferred region may be held on the site's servers. After you sign in, those details are available again. Clearing local site data does not delete the account's records.

The link you open can also select a region. A store may have a separate domain or address path for each market. Following a link to its Indian storefront can open that version immediately. In this case, the selected URL already tells the store which version you requested.

Earlier activity can matter as well. Google, for example, documents using IP information, device location, saved home and work addresses, and previous activity when estimating a relevant location for search. That describes Google's service; it does not mean an arbitrary website can read your entire browser history.

How does the browser share device location?

The Geolocation API is a browser feature through which a page can request an estimate of the device's geographic position. On ordinary public websites it is available in a secure context, normally HTTPS, and requires location permission. The result includes latitude, longitude, an estimate of accuracy and the time when the position was obtained. A permitted request may use a cached position if the page allows one, so opening a map does not necessarily produce a new measurement.

The browser and the device's location services determine how to obtain that estimate. Available sources can include GPS, nearby Wi-Fi networks, mobile network information and IP information. A laptop without GPS can therefore provide a position too. The API does not require one particular source or identify the source to the page. Coordinates returned by the browser should not automatically be described as GPS coordinates or an exact physical location.

Suppose the customer in India allows the store to obtain device location, and the browser returns coordinates in India. The page can send those coordinates to the store through the German proxy. The request then carries two different facts: it arrives from a German IP address, and its contents include a position in India. The proxy transports that information; it does not turn the supplied coordinates into coordinates in Germany.

A new permission prompt need not appear on every visit. The browser may still have a valid permission granted earlier. You can review that site's location permission in the browser settings; access may also depend on the operating system's permissions for the browser.

Denying this permission stops the site from obtaining a new position through that API while access remains denied. IP-based estimates and information already saved by the site remain separate sources. This explains why a website can still display a location even when you have not allowed it to request the device's position.

What do language and time zone tell the site?

A browser can send preferred languages in the Accept-Language request header. Page scripts can also read language preferences. These settings help the website choose a language the visitor understands. They do not require the permission used for device geolocation.

An English-language browser can remain in English while its owner travels between countries or uses a German proxy. If a German storefront supports English, it can display English text while still treating the connection as German. Even a preference such as en-US identifies a language variant, not a verified position in the United States.

JavaScript can also read the time zone exposed by the browser, for example through Intl.DateTimeFormat().resolvedOptions().timeZone. A website may use it to display an appointment in the visitor's local time. The value normally reflects the browser's environment, which may use an automatic or manually configured time zone.

A time zone name and a UTC offset are different values. An offset states the difference from UTC at a given time, and several countries can share it. Neither value independently establishes where the device is physically located. A website may compare language and time zone with other information, but a difference from the proxy's country does not, by itself, show that another IP address was disclosed.

Can the website learn another IP address?

A proxy setting applies to the traffic that the browser sends through that proxy; it does not establish that every connection from the browser or device takes that route. WebRTC, the browser technology used for real-time audio, video and data exchange, can discover addresses while preparing connections. Where the browser's rules and network configuration allow direct checks, they may disclose another public IP, such as the address of the customer's internet connection.

The result depends on the browser's privacy rules and network configuration. WebRTC is not a universal way for every website to recover the customer's public IP. A private local address such as 192.168.1.10 is also a different finding: the same address can exist in many unrelated local networks, so it cannot identify a country on its own.

DNS converts domain names into network addresses. A dedicated DNS test can identify the resolver handling its lookups. The resolver's country describes that server, which may be far from both the customer and the proxy. Some resolvers additionally send part of the IP address of the client that made the DNS request through the optional EDNS Client Subnet feature. Seeing a resolver in another country and exposing information about the client's network are therefore different results.

These mechanisms concern network information available beyond the ordinary page request. They should be investigated when a test shows an unexpected public address or other network data. A page displayed in the wrong language is not enough to establish that such a connection occurred.

Which information does the site give priority to?

The answer depends on the decision being made. A map's “near me” feature can use a permitted device position. A store can keep the country selected by a returning customer. A delivery calculation needs the destination of the parcel. These features can operate within the same visit and use different information.

There is no universal rule that GPS always overrides IP, or that an account's country always overrides both. The website decides which sources are available and relevant to each feature. It may use one source, fall back to another, or compare several.

Checkout makes this distinction particularly visible. A customer can browse a German catalogue and then enter a delivery address in India. The store may recalculate delivery, change the available products or apply its rules for that destination. For example, Shopify documents that the shipping address determines the customer's final market experience at checkout. This is a rule of the commerce system, not a new measurement of the proxy's IP.

Access is another decision. A service can identify the country correctly and still reject an action because of its account, network or availability rules. A general refusal does not reveal which information caused it. The relevant evidence is the specific explanation the service supplies, rather than the fact that a refusal appeared.

How can you tell what affected the result?

Start with the exact feature you are checking: the country assigned to the connection, a regional catalogue, nearby search results, language or delivery availability. Each can depend on different information. For a useful comparison, keep the proxy IP and page address the same while changing one relevant condition. Record the address used in each test rather than relying only on unchanged proxy settings; otherwise, rotation can change the IP at the same time as the setting you meant to test.

1. Inspect the site's own settings. Check its country selector, search area, delivery destination and the regional version in the URL. A visible selection may already explain the result.
2. Compare a returning visit with a fresh signed-out session. A separate test profile without the site's stored data helps examine the effect of saved state. First confirm that the profile uses the same proxy IP. A new private session uses site data separate from ordinary browsing, but it does not automatically change the connection or every browser setting.
3. Check what changes after signing in. If the previous region returns with the account, inspect its region and address settings. That behaviour points towards account-related information, although it does not reveal the site's entire decision process.
4. Review device location when the feature needs a current position. Check the site's location permission and any explanation it provides about the source of its location estimate. Nearby results and a saved delivery country need different checks.

In the shopping example, selecting Germany in the store's country menu addresses the saved storefront preference. If the task is to arrange delivery to India, the Indian destination remains relevant. If the site explicitly assigns the proxy IP to the wrong country, the question is instead about its geolocation data for that address. Identifying which result you need makes the next action specific.