Permissions & Access · Privacy Tests
Browser Extension Test
Check which of your installed extensions a website can detect, and why that still matters.
Inferred from side effects in this page
What a page cannot do
A website cannot list your extensions. There is no API for it, and this test does not pretend otherwise. It checks seven side effects a handful of very common extensions leave behind, and it cannot see extensions that leave none — which is most of them. A missing signal is not evidence the extension is absent.
On this page
Can a website detect my extensions?
The short answer is no, not as a list. Browsers once exposed a page-visible list of installed extensions, and every browser removed it because it was a fingerprinting goldmine. There is no supported API today that returns your extensions, and a site that claims to have read them is guessing from indirect evidence.
What is left is side effects. An extension that modifies the page — by injecting an element, a stylesheet or a global object — has made itself visible to any script on that page, because its work landed in the page’s own document. An extension that stays in its isolated world, which is the default and the great majority, leaves nothing to find.
One direction only
Detection is not evidence of absence. The rows above can only ever show what is visible, and for most people most of them will read as not seen even with a full set of extensions installed.
Signals a page can actually read
The seven checks in the panel are a representative sample rather than a survey. Each one is a known, documented side effect, and each is limited in what it proves.
- Injected DOM nodes. Grammarly adds a custom element to the document, and Dark Reader adds a stylesheet to the head. Both are plain, readable additions to the page, which is exactly why they are detectable.
- Global objects. Developer extensions set window.__REACT_DEVTOOLS_GLOBAL_HOOK__ and window.__REDUX_DEVTOOLS_EXTENSION__, and wallet extensions expose window.ethereum. A global is the loudest kind of side effect.
- Extension resource references. If a content script points the page at a file inside its own package, the resulting chrome-extension:// or moz-extension:// URL is readable in the DOM.
- Blocked or hidden content. An ad blocker announces itself by doing its job, which is the one signal that is genuinely hard to avoid.
What a page cannot do
The limits are enforced by the browser rather than by politeness, and they are worth knowing because they are the reason this test is short.
- List installed extensions. No API returns them, in any current browser. The row above records this rather than testing it.
- Read an extension’s storage. Each extension’s data is private to it. A page cannot reach it, and neither can another extension unless it is explicitly granted access.
- Fetch an extension’s files. A request to a chrome-extension:// URL from a page is refused, which the test confirms by attempting one and expecting the failure. The extension ID used is deliberately fake, and the block applies whether or not it exists.
- Read browser settings. The extensions page, the profile and the add-on manager are all outside what a site can see.
The permissions test covers the related question of what a page can ask your browser for directly, which is a short list too.
Detecting ad blockers, and why it works
Ad blockers are the exception to everything above, because their purpose is to change what the page receives. A blocker works by matching request URLs against filter rules and hiding elements whose class names appear on those lists, and both of those actions are observable from the page.
The test uses two probes. It places a bait element with the class names blockers routinely target and checks a moment later whether it has been hidden, and separately requests a well-known ad script and treats a refusal as evidence of blocking. Either one firing is enough to report a blocker as active. A timeout counts as inconclusive rather than as a pass, because a slow network and a blocked request look the same from here.
What none of this reveals is which blocker you use or what else it blocks. It is a yes-or-no signal about interference, and the dedicated ad blocker detector looks at the same question in more detail.
Why extension visibility matters
A single detectable extension is a strong signal precisely because it is rare. Knowing that someone runs a specific wallet, or a particular developer tool, narrows a crowd far more than knowing they run six extensions nobody can name. It is the same logic as any other fingerprinting vector: uncommon values identify, common ones do not.
That is the reason browsers removed the enumeration APIs in the first place, and the reason the remaining side effects are treated as acceptable: they require the extension to have already chosen to touch the page. A password manager that stays in its isolated world is not exposed, and neither is a translator that never injects anything.
The practical takeaway is modest. There is nothing to switch off here, since the visible signals come from the extensions themselves doing their work. What you can do is know which of your extensions are loud, and weigh that against what they give you. The fingerprint test shows where that signal sits among the rest of what identifies you, and the private mode test explains why a private window does not hide it.