IPvFoo shows which IP address actually served the page you are looking at

The icon answers the question the browser toolbar hides

IPvFoo is a browser extension written in JavaScript that adds an icon to indicate whether the current page was fetched using IPv4 or IPv6. Clicking the icon opens a pop-up listing the IP address for each domain that served the page elements.

That second part matters as much as the icon. A modern page pulls resources from a long tail of origins: a script host, a font CDN, an analytics endpoint, an image service, sometimes a login provider. The browser treats them as one document, and the address bar tells you nothing about any of them. IPvFoo makes the per-domain address visible, so you can see at a glance that the main document came over IPv6 while a third party asset came over IPv4.

The audience is narrow and specific: people who care about how a page was actually delivered rather than what the site claims about its own support. Dual-stack migration work, an ISP whose two address families behave differently, and a debugging session about a connection that works on one protocol and not the other are all cases where this is the tool that answers the question.

webRequest capture is what makes the address visible without extra traffic

The mechanism is the browser's webRequest API. The extension observes requests as the browser makes them, and reads the address from the network layer that the browser already used, so the information is captured privately and no additional network traffic is created.

That constraint is not incidental, it is the whole design. A different way to answer the same question would be to resolve the domain names yourself, either with a DNS lookup or with a request to an address lookup service. The project states the objection to that approach directly in the context of Safari: a Safari extension could in theory do its own DNS lookups, but that would create additional network traffic and may disagree with the browser's address selection.

That disagreement is the crux. A self-lookup tells you what a resolver returned at the moment you asked, from your vantage point. The webRequest approach tells you what this browser actually connected to, on this page load, including the address the browser picked for each origin. For a tool whose purpose is diagnosing real delivery, the second answer is the one that counts.

Safari is ruled out by the API, not by lack of effort

The documentation is unambiguous that IPvFoo cannot be ported to Safari, and it gives the reason rather than a plan: the webRequest API does not report IP addresses. That is a platform limitation, and the project points to issue 39 for the discussion.

The Safari paragraph is still worth reading because it sketches the fallback and explains why it is rejected. A Safari extension could perform its own DNS lookups, but that would create additional network traffic, and the result may disagree with the browser's address selection. So the alternative is not merely a worse version of the same feature, it is a different measurement with different error characteristics.

For a team that has to cover every browser, this is the practical boundary of the tool. Chrome, Firefox and Edge are covered, and the Chrome build can also be run on Edge because the two are identical. Safari is simply not on the list, and no setting changes that.

One codebase, two manifests, and the errors you get when you mix them up

IPvFoo shares a common codebase for Chrome and Firefox, but manifest.json is browser specific, and swapping the wrong one produces a specific error message. Firefox refuses the Chrome version with a temporary add-on installation error saying that background.service_worker is currently disabled and asking for background.scripts. Chrome refuses the Firefox version with errors stating that background.scripts requires manifest version 2 or lower, and that page_action requires manifest version 2 or lower.

That second error is the more informative one. The Firefox manifest targets manifest version 2, which the current Chrome no longer accepts, and it uses the older page_action key rather than the newer action key. The Chrome manifest uses the service worker model that Firefox's temporary add-on loader rejects.

The project handles this with the use_*_manifest.sh.bat scripts in the src/manifest directory, which switch between the two versions. For anyone running the extension unpacked from git, that script, or a manual copy of the right manifest file, is the difference between a working build and a rejected one.

The Makefile refuses to package a manifest that matches neither browser

The repository builds both packages with a Makefile, and the interesting part is the prepare target. It diffs the working manifest against the Firefox and Chrome versions and aborts if neither matches, with a message telling you the file is not a copy of either and that it is aborting. In other words, the build will not silently package a manifest you have edited by hand and left out of sync.

The targets and the copying they perform look like this:

all: prepare firefox chrome
firefox: prepare
	rm -f ${BUILDDIR}${NAME}-${VERSION_F}.xpi
	cp -f ${MANIFEST_F} ${MANIFEST}
chrome: prepare
	rm -f ${BUILDDIR}${NAME}-${VERSION_C}.zip
	cp -f ${MANIFEST_C} ${MANIFEST}

The Firefox target produces an xpi, the Chrome target produces a zip, and both exclude the manifest directory from the archive so that only the selected manifest ships. Versions are read out of the two manifest files with a sed expression that pulls the version field out of the JSON, and the version in the file name therefore follows whichever manifest is being packaged.

The repository layout follows the same split: src holds the extension sources, sprites holds the icon assets, tests holds the tests, and misc holds the screenshots referenced by the README.

Firefox search results need one setting changed before the reading is meaningful

There is a configuration caveat specific to Firefox, and it is easy to miss because the extension still works. To use IPvFoo with Firefox's default search engine, you have to uncheck the setting under Settings, Search, Show search terms in the address bar on results pages.

The reason is that a search results page is assembled from several origins. With the search terms shown in the address bar, the page includes an additional element from the search provider, and the per-domain list in the pop-up then contains an entry that is not part of the content you asked for. Turning the option off removes that element and leaves a list that reflects the page you actually wanted to look at.

That is the kind of detail that separates a tool you try once from a tool you keep. It also tells you something about the shape of the output: the pop-up is a per-origin address list, not a per-page verdict, so anything injected into the page by the browser or by another extension can appear in it.

The project ships no releases, so the web store is the update path

On upkeep, the facts are modest but clear. The last push to the repository was on 2026-10-01, the repository is not archived, and the project is released under the Apache-2.0 licence. There are no GitHub releases at all, which means the repository is not the place you get a packaged build.

The distribution points are the browser stores, and the README links the Chrome Web Store, the Firefox add-ons site and the Microsoft Edge add-ons site. Each store handles updates for installed users, so the absence of tagged releases is a distribution choice rather than a sign of an abandoned tool. For a developer who wants to modify the extension, the Makefile targets are the way in, with the manifest switch scripts needed to pick the right browser.

One last practical note. The pop-up lists addresses for the domains that served the page elements, so on a site served through a content delivery network the addresses you see are the edge addresses rather than the origin server, and on a page with a single origin you will see a single entry. Knowing which of those two situations you are in is part of reading the output correctly.

Editorial conclusion

IPvFoo fits a developer or network engineer who needs to confirm that a site is being served over both IPv4 and IPv6, and it is the wrong tool for Safari users, for anyone who needs historical or server-side data, and for sites whose pages are served by a CDN where the per-domain list is the only useful output. Verify first that the extension reports what you expect on a dual-stack site, and check the Firefox search setting before drawing conclusions from a search results page.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. pmarks-net/ipvfoo on GitHub
4. README