Source: https://bscan.info/blog/can-websites-see-browsing-history Language: en No site gets a list of where you have been. The referrer, trackers and your ISP each see a slice. Run the live test on your browser and see who sees what. # Can Websites See Your Browsing History? Live Test Published November 12, 2026 You looked at hiking boots once, on one store’s site. Now every site you open wants to sell you hiking boots. The obvious conclusion is that websites can read your browsing history and pass it around. They cannot. On current browsers no website can read the list of sites you have visited, and you get followed anyway. The widget on this page asks your own browser what it will tell a page about where you have been. Almost nothing, and on purpose. **The short version:** a page cannot read your browser history, meaning the list of sites you have visited. The trick that used to fake one, probing `:visited` links, has been shut down in stages since 2010. What a page can still read is small: the site you came from, how many steps your back button has, and its own records of you. The rest of the picture is assembled by trackers that sit on many sites, and by the networks that carry your traffic. ## No API hands over your history Look at what `window.history` gives a script: `back()`, `forward()`, `go()`, `pushState()`, `replaceState()`, `state`, `scrollRestoration` and a `length`. Nothing in it returns an address. `history.length` counts the entries of the current tab and tops out at 50 in Chrome and Firefox (Safari keeps 100), so it says little about how much you have browsed. The newer Navigation API, `navigation.entries()`, does return addresses, but only for entries in the current tab that share the page’s origin, and only the unbroken run of them. A page reads its own trail and nobody else’s. In my test on Chromium 156, after following a link from one origin to this page on another, `history.length` said 2 and `navigation.entries()` listed one entry, the current page. I did not test Firefox or Safari. ## The :visited trick, and how it died For years there was a back door. Browsers paint visited links in a different color, and a page was allowed to ask what color a link ended up. So a script made an invisible link to a bank’s login page, read its computed color, and knew whether you had been there. Mozilla put the speed at hundreds of thousands of links per minute, with no prompt and nothing for you to notice. In March 2010 [Mozilla announced the fix](https://blog.mozilla.org/security/2010/03/31/plugging-the-css-history-leak/): `getComputedStyle` would answer as if every link were unvisited, and visited links could only be styled with a few color properties. Every major engine works that way now. The first row of the widget shows it. It asks about a link to the page you are reading right now, which you have visited by definition, and your browser says no. A lie about colors only closes the direct route. Researchers kept finding side channels, like Paul Stone’s 2013 attack that times how long a visited link takes to repaint, and each one needed its own patch. Chrome’s answer, [available since version 136](https://developer.chrome.com/blog/visited-links) on desktop and Android, changes where visits are stored. The visited-link list stopped being one list. Each entry is stored under three keys: the link address, the top-level site you were on, and the frame that showed the link. A page on `blog.example` looking up the bank now queries a different key than the one your bank visit was stored under, and finds nothing. What a hidden-link probe can learn Before Chrome 136, if a side channel works Your visited links - `bank.example/login` visited from bank.example - `news.example/story` visited from a search page - `blog.example/post` visited from blog.example A page on blog.example asks about three links - `bank.example/login` visited: leaked - `news.example/story` visited: leaked - `blog.example/post` visited (it already knew) its own page With one shared list, a page that finds any side channel learns where you banked and what you read. A site’s own pages still show as visited wherever you first opened them, and so do links you clicked from that site. That costs nothing, because the site already knows both. As far as I could verify, Firefox and Safari have no equivalent of the partitioning, and neither does Chrome on iOS, which runs on WebKit. The 2010 rule was not airtight even so: Apple’s [Safari 26.6 notes](https://support.apple.com/en-us/128073) from July 2026 fix a WebKit bug that let websites know whether you had visited a given link. ## What can a website see about your browsing? **The referrer.** Arrive from a search result and the page may learn which site sent you. Since Chrome 85 and Firefox 87 the default for cross-origin navigations is to send only the origin, so `https://www.google.com/` and not your query, unless the sending site sets its own policy. Safari trims cross-site referrers too. In the same Chromium 156 test, the page I came from had a long path and `document.referrer` returned only its origin. If you typed the address or used a bookmark, it is empty. It is also why a site you click through to cannot see what you searched for: your searches live with the search engine and your account, not with the page. **Its own records.** This is the big one, and it is boring. A site that set a cookie when you visited last Tuesday recognizes you this Tuesday. It is a history of one site, not of the web, and every site you visit keeps one about you. The owner of a site sees its own visitors in analytics, with page addresses, IP addresses and referrers, and that view stops at the edge of the site. **A few leaks at the edges.** Cross-site tricks can sometimes tell whether you are logged in somewhere else, by loading something that only works for signed-in users and measuring what happens. The [XS-Leaks wiki](https://xsleaks.dev/) catalogs the family. It tells a page one bit about one site at a time, and some channels get closed while new ones keep appearing. Nothing in it resembles a list. ## How trackers still build a browsing history of you The ads mostly follow you because of who else is on the page. An ad network’s script sits on the shoe store and on the news site. If it can recognize you on both, it holds a browsing history, assembled one site at a time, with no help from your browser’s history at all. The FTC has a plain-language [overview of how sites and apps collect this](https://consumer.ftc.gov/articles/how-websites-and-apps-collect-and-use-your-information). Safari blocks third-party cookies outright, and Firefox partitions them per site. As of November 2026 Chrome still allows them by default. Cookies are only one way to recognize you. A [canvas fingerprint](https://bscan.info/blog/canvasHash) can stay the same on every site in most browsers without storing anything, which is why clearing your history does nothing against it. A tracker’s script also runs inside the page it sits on, so it can read that page’s address and title, not just note that you showed up. Our post on [what a page can observe during a visit](https://bscan.info/blog/can-websites-see-tab-switching) covers the rest. ## Who else can see your browsing history Take the page out of the picture and look at everyone else on the route between you and a site. Most of them see only a part. The synced browser account is the exception. Who sees which slice of your history Who Which sites Which pages and searches What the pages show The site you are on Sees part of it: previous site name, if sent Does not see it: only its own pages Does not see it: only its own content A tracker embedded on both sites Sees it: where it is embedded, if it recognizes you Sees it: addresses of the pages it sits on, if its script runs in the page Sees part of it: page title and whatever else its script reads Your ISP or Wi-Fi owner Sees it: usually domain names, and the server IPs Does not see it: paths are encrypted on HTTPS Does not see it: encrypted Your synced browser account Sees it: everything, if sync is on and the vendor can read it Sees it: full addresses, if readable Does not see it: not stored - Sees it - Sees part of it - Does not see it Most rows see a slice. Only a synced account can see everything, and only if the vendor can read it. A VPN does not remove the ISP's slice, it moves it to the VPN company. Your ISP, or whoever runs the Wi-Fi in the hotel or the office, cannot read page addresses on HTTPS sites. It usually still sees the domain names, because the DNS lookup and the start of the TLS connection name the site. Encrypted DNS and Encrypted Client Hello can hide that on some sites, but the server’s IP address stays visible. A VPN does not erase the slice. It hands most of it to the VPN company, and your ISP is left with the knowledge that you use one. We cover how sites spot that in [VPN detection](https://bscan.info/blog/vpn-detection). The row people forget is their own browser account. If history sync is on, a full list of the addresses you opened can sit on the vendor’s server. In Chrome, Google can read synced history unless you set a sync passphrase, and with one only the addresses you typed in the address bar sync. Firefox Sync and iCloud encrypt history, so those vendors cannot read it. ## Does incognito, a cleared history or a phone change anything? Private browsing stops your own browser from saving the list and starts you with empty cookies. The site, your ISP and the Wi-Fi owner still see the visit, and in most browsers a fingerprint still recognizes you. Safari, Firefox in private windows, Brave and Tor add noise or uniformity that makes that harder. Clearing your history wipes the list your browser keeps, and the synced copy with it, but not what sites, trackers or your ISP already hold. An account activity log, such as Google’s My Activity, keeps its own copy until you delete it there. A phone follows the same logic: the page gets the same few readings, and the history that matters sits in your account or on the network, not in the browser. So when the worry is a partner or a parent, check two places: an account that both of you can open, with its sync and activity log, and the network the traffic runs over. ## What to actually do 1. **Check the first row of the widget.** It should say “Closed”. If it says “Leaks”, your browser predates the 2010 fix or is missing a patch. Update it, and on Safari make sure you are on 26.6 or later. 2. **Check what you sync.** Open your browser’s sync settings and decide whether history needs to be in the account. In Chrome, a sync passphrase stops Google reading it. Firefox Sync and iCloud encrypt history by default. 3. **Clearing history will not stop the tracking.** It wipes the list your browser keeps, and the synced copy with it. It does not touch cookies or site data, and it does not reach what sites, trackers or your ISP already hold. Clearing cookies cuts the cookie half of the tracking, and in most browsers the fingerprint half survives both. 4. **Keep identities apart on purpose.** Trackers work by linking, so anything that must not be linked needs its own cookies, storage and fingerprint. If you run several accounts that way, [Incogniton](https://www.incogniton.com/?utm_source=bscanInfo&utm_medium=Website&utm_campaign=BrowsingHistoryBlog) gives each profile its own, so a tracker that sits on two sites sees two strangers, as long as you open each site from a different profile and give each profile its own IP address through a proxy. The widget checks what a page can read. The [full browser scan](https://bscan.info/) checks what a page can work out about you from properties that look harmless on their own: the fingerprint hashes, the leaks around your IP address, and whether your browser tells one consistent story. [Run the full browser scan](https://bscan.info/) ## Keep reading [ ![Can Websites Detect Remote Desktop? Test the Clues](https://bscan.info/remoteDesktopCover.svg) Can Websites Detect Remote Desktop? Test the Clues ](https://bscan.info/blog/can-websites-detect-remote-desktop)[ ![Can Websites Detect Inspect Element and Open DevTools?](https://bscan.info/devtoolsCover.svg) Can Websites Detect Inspect Element and Open DevTools? ](https://bscan.info/blog/detect-devtools)[ ![Can Websites See Your Computer Name? Check the Claims](https://bscan.info/computerNameCover.svg) Can Websites See Your Computer Name? Check the Claims ](https://bscan.info/blog/computer-name) --- This is the page's server-rendered documentation. Interactive browser tests, file processing and permission prompts require the HTML page; Markdown does not contain live measurements or process files.