1. Start with a ten-minute privacy baseline

This guide focuses on current desktop Chrome and Firefox on Windows and macOS. It aims to reduce unnecessary disclosure to websites, embedded trackers and other people using your device. A workplace administrator, internet provider, VPN provider and logged-in service see different parts of your activity; no single switch makes you invisible to all of them. Update the browser first, record its version, and use Settings search if a translated menu has moved.

  1. Block new location requests and review sites that already have permission.
  2. Review operating-system location access for the browser; keep essential navigation features as deliberate exceptions.
  3. Block Chrome third-party cookies or use Firefox Enhanced Tracking Protection; repair problems with narrow site exceptions.
  4. Enable HTTPS protection, review DNS settings, remove unnecessary extensions and keep a separate profile for general browsing.
  5. If hiding your residential or mobile connection IP from websites matters, use an appropriately scoped, trusted network service and verify its actual route.

Save a short record of the original settings. Change one group at a time so that a broken login, video call or company intranet has a clear rollback path.

2. How a page can infer your location without a location prompt

ChannelWhat it can revealUseful control
Connection IP, including IPv6Network operator and an estimated country or area; accuracy varies.Verify routing through your chosen VPN or proxy.
Permission-based geolocationA device location estimate, potentially much more precise than IP.Browser permission plus OS permission.
WebRTC connectivityConnection candidates and routes used for real-time communication.Verify WebRTC routing separately from ordinary page loading.
DNS queriesDomain lookups visible to the resolver and possibly the local network.Understand the resolver, encryption and VPN DNS route.
Account, cookies and saved activityYour identity, previously supplied addresses and earlier activity.Separate profiles and account-level privacy controls.
Language, timezone and fingerprintHints and a configuration that may help link visits.Built-in anti-tracking, minimal extensions and identity separation.
Uploaded photos or documentsEmbedded coordinates, addresses or visible identifying details.Inspect and sanitize the actual copy you share.

Google's location explanation distinguishes connection IP, device signals, saved activity and supplied home or work addresses. Blocking one channel leaves the others available. A site guessing the correct city does not by itself prove GPS access, a VPN failure or a precise home-location leak.

3. Chrome: block location requests and remove old exceptions

  1. Open Settings → Privacy and security → Site settings → Location. On desktop you can also enter chrome://settings/content/location in the address bar.
  2. Under default behavior, select Don't allow sites to see your location. Chrome normally asks; blocking is a choice you make.
  3. Review the sites already allowed to access location. Remove an unneeded permission or change that site's Location setting to Block. A new default is not a substitute for inspecting existing exceptions.
  4. For a particular page, open the site controls beside the address, choose Site settings and check Location. Reload the page after changing it.
  5. When you intentionally need a map or delivery service, allow only that service for the task, then revoke the permission when finished.

Chrome's location help explains the permission flow and location-service estimate. A blocked permission does not suppress the connection IP sent to the web server. A page can also display an old location already stored in its account or site data.

4. Firefox: block new requests and inspect existing permissions

  1. Open Settings and search for location. In the privacy or permissions section, open the Location → Settings… permission list.
  2. Enable Block new requests asking to access your location and save the change.
  3. Review existing Allow entries. Change an unnecessary entry to Block, or remove it while keeping new requests blocked. Blocking new prompts does not revoke an existing Allow.
  4. For the current site, use its permission indicator or Page Info → Permissions to inspect Access Your Location. Reload after editing.
  5. If you later need location, temporarily adjust the relevant permission and return to the list afterwards.

Mozilla's location documentation describes a permission-based service that can use nearby Wi-Fi information and the IP address to estimate location. Desktop computers can locate themselves without a GPS chip. Do not assume that disabling GPS on another device disables a laptop's Wi-Fi-based location service.

5. Check the OS layer, and treat phones separately

On macOS, open System Settings → Privacy & Security → Location Services and review the browser if it appears. Prefer a targeted application change over disabling useful location services for the entire computer. On Windows 11, open Settings → Privacy & security → Location; Windows 10 and individual app controls differ. Search Settings for Location if needed. Some desktop applications do not have the same per-app switches as store applications.

Chrome documents an additional Windows permission layer from version 144: allowing a website can trigger a system request as well. The OS decision and the website decision are separate. Apple also explains that other methods can still estimate location when Location Services is off. Neither OS switch changes the IP of an ordinary connection.

On Android, review the browser under Settings → Apps → [browser] → Permissions → Location, then check its website permissions too. Device vendors may rename the path. On iPhone and iPad, review Settings → Privacy & Security → Location Services → [browser]; app settings may also expose the same control. Choose Never if appropriate, or disable Precise Location when you intentionally allow approximate access. Approximate access still reveals an area. Do not paste desktop internal URLs or assume desktop VPN and extension features exist on mobile.

6. Chrome: reduce cross-site tracking without breaking everything

Open Settings → Privacy and security → Third-party cookies and choose Block third-party cookies if it fits your needs. Review exceptions as well. First-party cookies keep the site you are visiting signed in; third-party cookies can connect activity through embedded services. Blocking the latter does not block every tracking technique or remove the first party's knowledge of your visit.

If an embedded sign-in or widget fails, identify the specific site and use a narrow, preferably temporary exception. Do not permanently allow all third-party cookies to repair one page. To clear one site's stored data, use See all site data and permissions, search for its domain and delete that entry. Expect a sign-out and lost preferences; this does not delete the service's server-side records. These controls are described in Chrome's cookie help.

Also review Privacy and security → Ad privacy. If your version and region show Ad topics, Site-suggested ads or Ad measurement, inspect each and turn off the optional features you do not want. These are separate from cookie permissions. Do not rely on an old article claiming that Chrome universally removed third-party cookies or that an Incognito IP-protection experiment hides all traffic: Google's October 2025 update lists IP Protection among retired Privacy Sandbox technologies.

7. Firefox: use tracking protection, then repair narrowly

Open Settings, search Enhanced Tracking Protection and review Standard or Strict. Mozilla documents Total Cookie Protection in Standard mode, keeping cookies partitioned by the site where they are used. Strict adds stronger blocking that can interfere with sign-in, embedded video or other page features. Choose it deliberately, then reload and try your essential sites.

If one page fails, inspect the shield panel beside its address and the blocked categories. Test a site-specific exception, then remove that exception if it was not the cause. Avoid switching off protection globally after the first broken page. Mozilla describes the modes and exceptions; cookie partitioning is not an IP-hiding service, and the site you log into still recognizes your account.

Keep anti-phishing, malicious-download protection and browser updates enabled. Reducing tracking does not require disabling protections that warn about harmful sites. HTTPS settings in the next section protect transport, not the honesty of a website.

8. Private windows, profiles and containers solve different problems

In Chrome choose New Incognito window, or press Ctrl+Shift+N on Windows / Command+Shift+N on Mac. In Firefox choose New Private Window, or use Ctrl+Shift+P / Command+Shift+P. Chrome Incognito and Firefox Private Browsing limit what ordinary browsing history and temporary site data remain locally after the private session ends. Downloads and deliberately saved bookmarks can remain. Close all private windows to end that private session; opening a second private window is not necessarily a separate identity.

Private browsing does not hide your connection IP from sites or make your activity invisible to an employer or internet provider. Logging into your normal account identifies you to that service inside a private window too.

A useful workflow is a work profile, a personal account profile and an unconnected general-browsing profile. In Chrome's profile menu, add a profile and choose not to connect it to your usual account if separation is the goal. Firefox profiles similarly separate browser data; profile management UI varies by version. A profile is an organizational boundary, not a password-protected account against another person with access to your computer.

Firefox Multi-Account Containers can keep site cookie contexts apart within a profile. They are unavailable in Private Browsing or the Never Remember History configuration. Containers alone do not create different network routes or erase browser fingerprints. Opening the same account in two containers still identifies that account to its provider. For another person sharing your computer, use a separate OS user account and screen lock.

9. Choose network protection by its scope

ToolMain benefitBoundary to verify
HTTPSEncrypts transport to the site.The site sees its own requests and your connection IP.
DNS over HTTPSEncrypts supported lookups to a resolver.The resolver still handles queries; it does not replace the web connection IP.
Browser proxy or extensionCan relay traffic within its configured scope.Other apps, UDP, DNS and excluded sites may follow other routes.
Device VPNCan route a wider set of device traffic.Check split tunneling, IPv6, DNS, disconnect behavior and provider trust.
Tor BrowserCombines Tor routing with browser privacy defenses.Use the dedicated browser; identity disclosure and endpoint compromises remain possible.

A correctly routed connection normally exposes the relay's public IP to the destination rather than your home or mobile IP. This transfers some trust to the relay operator; it does not hide data you send to a logged-in service. Avoid choosing a provider only because it says free or no logs. Review its ownership, privacy policy, independent evidence, supported platforms and documented failure behavior.

If you need stronger separation from ordinary browsing, consider the dedicated Tor Browser rather than pointing a normal Chrome or Firefox profile at a Tor proxy. Keep its standard configuration and avoid extra extensions. Speed, site compatibility and account prompts may differ. Tor's official guidance also rejects a guarantee of perfect anonymity.

10. Firefox's built-in VPN: a useful feature with a specific boundary

As reviewed on 2026-11-02, Mozilla documents a built-in VPN progressively available since Firefox 149. It uses a secure proxy for browser traffic, requires a Mozilla account and has a 50 GB monthly allowance. Availability depends on rollout and eligibility; updating alone does not guarantee the icon. It is distinct from the full-device Mozilla VPN product.

If available, open the toolbar VPN panel, complete setup and confirm it is active for the site you are using. Inspect site exceptions and remaining data. At the limit protection becomes unavailable until reset; do not assume paused means all browsing is blocked. Check status after reconnecting or reaching the allowance. Other applications and documented service exceptions are outside the browser feature's scope; location permissions and account identity remain separate controls.

11. WebRTC: an ordinary IP check is not the whole test

WebRTC connection setup can expose network addresses in connectivity candidates. The route used for a video call may differ from an HTTP page routed through a browser proxy. Denying microphone or camera permission is not a universal WebRTC network control: connection setup can occur without capturing either device.

Distinguish a public IP belonging to your home provider from private addresses such as 192.168.x.x, 10.x.x.x and obscured .local candidates. A local address or mDNS label alone is not proof that a website learned your residential public IP. Compare results with your intended route and the address family involved.

Use your trusted provider's WebRTC guidance or a test endpoint you control, and test a real call if you depend on conferencing. If a residential public address appears while HTTP uses the relay, review UDP routing, split tunneling and the provider's documented WebRTC support. Chrome has managed policies and extension APIs for IP handling, but these are not a universal consumer Settings switch. Do not install several unknown WebRTC-blocking extensions or copy obsolete flags. Disabling the feature can break calls; test any documented, reversible change and undo it if unnecessary.

12. HTTPS and DNS: protect the route without misreading the switches

In Chrome, open Settings → Privacy and security → Security and review Always use secure connections and Use secure DNS. In Firefox, search Settings for HTTPS-Only or the current HTTPS protection option, and for DNS over HTTPS. Retain warnings rather than clicking through certificate errors. Chrome's security help and Mozilla's HTTPS help describe the options.

Chrome's automatic Secure DNS mode can fall back to unencrypted lookup; its selected custom-provider mode is documented differently. Firefox's DoH protection levels have different fallback and network-detection rules. Maximum protection warns when secure resolution fails, but a per-domain exception can permit system DNS. Read the description shown in your version instead of treating every On state as fail-closed.

When a VPN provides DNS, check its instructions before selecting a competing browser resolver. Firefox's default DoH detection may leave it inactive when a VPN or enterprise configuration is detected; that status alone does not establish a leak. Browser DoH may use a different resolver while still travelling inside the tunnel. A resolver located abroad does not prove the web connection uses that country, and a resolver in your country does not alone prove a DNS leak. Separate three questions: who resolves the name, whether the lookup is encrypted, and which network path carries it. Company domains and captive Wi-Fi portals may need specific handling; avoid disabling protection globally without identifying the failure.

13. Account history, fingerprinting and extensions

Signing out of Chrome sync is different from signing out of Google on a webpage; Mozilla account sign-in is different from a website login too. Review each separately. For Google, open Google Account → Data & privacy → History settings / My Activity and inspect the controls currently presented, including Search services history, Web & App Activity and Timeline where available. Google documents these as separate controls. Turning off Timeline does not delete every other saved location signal; deletion and future collection are separate decisions.

A timezone or preferred language can suggest an area, but neither proves where you are. Fonts, graphics behavior, screen properties and other signals may help link visits. Firefox's built-in fingerprinting protection reduces some of this exposure, not all identification. Random user-agent changes, unusual font packs and many privacy extensions can create inconsistent or distinctive configurations and break sites. Start with maintained built-in defaults, not a large unexplained about:config recipe.

Open Chrome's chrome://extensions or Firefox's Add-ons and themes, remove unused items and inspect site access for the rest. Prefer access only on necessary sites where supported. An extension allowed to read and change all pages receives substantial access; a privacy label is not evidence it behaves safely. Review private-window access separately. Chrome's extension help explains site-access controls. Do not install a browser root certificate merely to use a supposed privacy extension.

14. Links and shared files can disclose what settings cannot hide

When sharing a link, remove obvious marketing parameters such as utm_source only after checking that the shorter link still opens the intended public page. Some parameters are required for document access, invitations or signatures; do not strip them blindly. Use the platform's public share flow instead of forwarding a private session or account URL.

Before uploading a photo, inspect its location metadata and visible details such as street signs or shipping labels. Apple documents ways to remove or exclude photo location. Export a sanitized copy and check that copy; a messaging service may remove metadata in one workflow and retain it in another. Screenshots, PDFs and documents can expose addresses, author names or other clues even if they have no GPS fields. Browser permissions do not sanitize files you intentionally send.

15. Verify results and diagnose the remaining city clue

A useful check records the browser version, OS, time, profile, permission state, network mode and whether the test account is signed in. Use a small number of trusted test services or your own endpoint: each external test learns the IP and details you send it. These are instructions for your own setup, not a claim that this article tested your device.

CheckExpected resultIf it differs
Location permission listNew requests blocked; unnecessary Allow entries gone.Inspect both site exception and OS permission; reload.
HTTP public exitA trusted endpoint or your server log sees the intended relay address.Check whether that browser or site is excluded, and whether the service is active.
IPv4 and IPv6Both tested families follow your intended policy, or an unsupported family is deliberately blocked.Check the VPN's IPv6 support. An IPv4-only test says nothing about IPv6.
WebRTCNo unintended residential public candidate in the tested context.Review UDP and WebRTC support; do not treat .local or private candidates as a residential leak.
DNSThe observed resolver and route match your design.Review browser DoH, system DNS, VPN DNS and per-domain exceptions.
Disconnect behaviorA documented blocking mode actually blocks a harmless test request when the tunnel drops.Test only if safe for your current work; a connected-state check does not establish a kill switch.
Essential sitesSign-in, calls and required intranet pages work with narrow exceptions.Undo one recent change at a time, rather than globally removing protections.

For a simple HTTP exit observation, if you choose to trust Cloudflare as the observer, open https://www.cloudflare.com/cdn-cgi/trace in the browser you are checking and inspect the ip= line. Cloudflare receives this request. Its verification documentation uses this field to inspect an exit address. The colo= field identifies a serving data center, not your physical location, as its routing explanation makes clear. This observes one request to one endpoint; it does not certify every site, IPv6, DNS or WebRTC.

Alternatively, a self-controlled HTTPS endpoint can log the incoming source IP; if it sits behind a CDN, interpret the CDN's trusted client-IP metadata correctly. Do not confuse the server's own address with the visitor's. DNS and WebRTC require their own checks. Retest after browser, OS or network-client updates and after changing Wi-Fi networks.

If a site still shows your city, work through the evidence: first confirm its current connection IP; then review location permission; compare a separate, signed-out profile; inspect the site's stored address or chosen region; finally check language and timezone clues. Do not clear all passwords or reinstall the browser as the first response. A cached city, account address or geolocation-database error can explain the display without a new precise-location disclosure.

For everyday browsing, the practical baseline is blocked unnecessary permissions, tracking protection, HTTPS, minimal extensions and separate profiles. Add a verified network route when IP privacy matters. For stronger anonymity needs, use a tool designed for that purpose and preserve its standard protections. Repeatable observations are more useful than a single green “privacy score.”