Extension fingerprinting
Browser Extensions Can Reveal What You Do Online
A website cannot simply ask for a list of your extensions. It can look for the traces they leave in the page, then use those clues to recognize a browser or infer something about its user.
Overview
Your installed software can leave evidence in a page.
Browser extension fingerprinting is the detection and combination of extension-related signals to recognize a browser or profile its user. Ordinary websites do not have a general API that returns your installed-extension list. They infer parts of that list from resources and behavior they can observe. [5]
An extension can be trustworthy and still detectable. A password manager may add a control to a form; a reading aid may change text; a research tool may load its own icon. The website does not need access to the extension’s private data to notice a visible effect.
This is different from a malicious extension collecting your browsing history. In extension fingerprinting, the observer is the site—or a script running in it—and the extension is a source of evidence. Both risks deserve attention, but they have different causes and defenses.
resource · DOM · style · actionLive demonstration
What can this page actually see?
Start the local observer, then interact with the sample area. It watches for page-visible extension resource addresses and changes to that area. Results stay in this tab and disappear when you leave.
Give an extension somewhere to act.
This is a real piece of the page. Start observing, then focus the sample field or select the passage. An extension may add a control, alter an element, or load an icon.
Research notes move across websites. A browser tool might annotate this sentence, add a button, or change its appearance.
Visible traces, not an inventory.
The observer reads page elements and resource addresses already exposed here. It never asks the browser for installed extensions.
- Start observing to inspect this page locally.
How to read this: A resource with an extension URL is a direct clue. A changed page element is only a clue; the page alone cannot establish whether an extension, browser feature, or another script caused it. Zero visible traces never means zero installed extensions. No catalog requests, storage, analytics event, or result transmission are used by this demo.
How can a few traces become a fingerprint?
How observations become a fingerprint
A scanner can record positive detections, uncertain results, and behavior signatures in a fixed order. It may compare the resulting vector directly or hash a serialized representation. A hash adds no new identifying information; it is a compact representation of the observations already collected.
One popular extension may be shared by many people. A combination of tools, settings, and observable versions can narrow the group. Adding canvas, language, platform, or account information may narrow it further. The gain depends on real prevalence and correlation: several tools commonly installed together do not supply independent bits of evidence.
A 2018 user study found that 54.86% of participants with at least one detectable extension had a unique extension combination within its sample. That is a historical result from a particular study, not the chance that your browser is unique today. The researchers also found privacy extensions more useful than harmful overall. [8]
Fingerprints change as extensions are updated, removed, or restricted. Recognition systems can compare partial overlap instead of requiring an identical hash. Cross-site recognition also needs an observer able to obtain and compare sufficiently similar evidence on both sites; detectability alone does not establish that data has been shared.
The detection pipeline
There is more than one way to spot an extension.
- 01
Probe a packaged resource
The site starts with a catalog of known extension IDs and file paths. It attempts to load an exposed image, script, or other asset. A successful load can reveal an extension even if that extension has not visibly changed this page. Source
Known ID + accessible file - 02
Inspect the page’s structure
Extensions may add buttons, wrappers, attributes, or links to the document. A page can inspect its own DOM for those signatures. Injected extension URLs can expose a resource address that was otherwise difficult to guess. Source
Elements, attributes, URLs - 03
Measure an injected style
A page creates elements designed to match an extension’s CSS rules, then measures their appearance. A hidden element, changed font, or altered size can become a signature. Detecting a generic content blocker is easier than identifying exactly which blocker caused the change. Source
Computed style + layout - 04
Trigger a behavior
Some extensions only react after typing, selection, clicks, or other interactions. Research has shown that action-driven tests can expose extensions missed by passive checks. Page-visible messages or behavior can add further evidence. Source
Action → observable response
Learn more about resource and page-based detection
Why a known file is enough
In Chromium, a resource address can take the form chrome-extension://<extension-id>/<file-path>. Extension manifests decide which bundled files are web-accessible. Where the visiting origin is allowed, a page may load a known resource without asking the browser for an extension inventory. [1]
A failed request is ambiguous: the tool may be missing, the file may have moved, its address may be randomized, or access may be blocked. An error in the developer console shows an attempted operation; it does not prove that the matching extension is installed or that a server received the result.
Why isolation is not invisibility
Content scripts normally run in a separate JavaScript environment. That keeps their internal variables away from page scripts. However, they can modify the shared document. A site can observe those modifications without entering the extension’s isolated environment. [4]
Style and interaction-based attacks extend this idea: instead of looking for a known filename, a test looks for a characteristic response. Research has demonstrated both injected-CSS detection and action-triggered detection. These are reasons a resource-only test cannot certify that extensions are invisible. [6] [7]
Inference Based Attacks
The inventory can tell a story about you.
Extensions are chosen for a purpose. Even without a unique fingerprint, their functions may suggest interests, accessibility needs, work activities, or affiliations. Carnus explored this privacy problem by classifying extension functionality, including categories related to religion, health, and politics. [5]
- ObservationA tool leaves a trace
- InterpretationThe tool has a known purpose
- InferenceA profile gets a new label
| Observable tool category | A profiler might infer | Another explanation |
|---|---|---|
| Tracker blocker or anti-fingerprinting tool | Privacy awareness; willingness to restrict tracking | An IT policy, a default installation, or an attempt to reduce ads rather than a deeply held belief. |
| Scripture reader, prayer aid, or religious calendar | Possible religious interests or affiliation | Research, language study, curiosity, or use by someone else on a shared browser. |
| Reading, focus, or accessibility aid | Possible accessibility needs or working preferences | A convenience preference or a workplace requirement. It cannot establish a diagnosis. |
| Job-search or recruiting tool | Possible career exploration or recruiting activity | Professional responsibilities, an old installation, or helping someone else. |
| Citation manager, developer tool, or enterprise security agent | Possible occupation, employer tooling, or research workflow | Personal projects, education, testing, or a tool installed but rarely used. |
Software choices do not establish personality traits. A privacy tool may suggest privacy consciousness; it does not reliably measure someone’s openness, anxiety, values, or political commitments. A religious tool does not prove belief. An accessibility tool does not prove disability. Those are hypotheses, not facts.
The risk is that an uncertain label can still affect how someone is treated. A system could use it to tailor persuasion, classify an account, or flag a workflow. Linking that label to a signed-in account makes the inference attributable; an employer-specific extension can also expose something about an organization.
These are plausible consequences of collecting the inventory. They are not evidence that LinkedIn—or another named service—uses an extension list to make every inference shown here. The sensitive character of a tool is a reason to limit collection, not a reason to stop using tools you need.
A real-world case
When the software inventory meets a professional identity.
LinkedIn is scanning your browser extensions.
404’s analysis described resource probing alongside DOM inspection. The number is a count of scan targets, not installed tools or confirmed detections on one visitor’s device.
Read the LinkedIn investigation →Read the technical evidence and limits
BrowserGate’s published technical analysis documents extension checks and telemetry in the LinkedIn code it examined. In a signed-in session, results can be associated with an account that already has a name, employment history, and professional network. That removes the need to infer a person’s identity from the extension combination alone. [14]
LinkedIn says its rules against scraping, automation, and certain extensions protect members and prevent abuse. An anti-abuse purpose is separate from the questions of what is collected, how broadly the scan reaches, and what happens to the results. Its stated policy is not independent proof of every technical claim or downstream use. [15]
Keep the evidence layers separate: scan code shows a detection attempt; a successful response shows a local signal; a captured outbound payload shows transmission; documented server behavior establishes a particular use. The April article and BrowserGate analysis are dated records, not a live test of the code LinkedIn serves today.
Compare the defenses
A browser can close one channel while another stays open.
The useful question is which detection method a protection interrupts. This is a documentation-based comparison reviewed October 2, 2026, not a test-based browser ranking.
| Browser | Protection mechanism | What it does not establish |
|---|---|---|
| Chrome & Edge | Manifest V3 supports origin-scoped resources and opt-in dynamic resource URLs. Chrome enabled dynamic URL support starting in version 130. Source | A fixed-ID resource exposed to the visiting origin can still be probed. Manifest V3 alone does not mean every extension uses dynamic URLs. |
| Firefox | Extension resource hosts use installation-specific UUIDs instead of a shared store ID. A catalog cannot simply substitute the public add-on ID into a predictable resource URL. Source | The random host protects address guessing. Page changes and leaked resource URLs are separate surfaces. ETP also blocks known fingerprinting scripts, with list coverage and exceptions. |
| Brave | Shields combines tracker blocking with fingerprinting defenses; Brave randomizes selected browser outputs. Installed Chromium extensions still need careful resource and permission design. Source | Canvas or audio randomization does not, by itself, conceal an extension’s exposed file or DOM changes. Do not equate a generic fingerprinting setting with an extension-invisibility guarantee. |
| Safari | WebKit has documented randomized extension resource hosts. Safari’s enhanced Private Browsing disables extensions with website or history access by default unless the user enables them. Source | Content blockers are treated differently. Extensions that do run can still alter a page. A browser-specific resource scheme alone is not proof against every technique. |
| Tor Browser | The Tor Project’s approach emphasizes a consistent browser configuration and explicitly discourages installing additional add-ons. Source | Additional extensions can make the browser stand out and change its behavior. A Tor circuit hides the network route; it does not erase page-visible extension effects. |
Learn more about browser protections
Three defenses that solve different problems
Restricting origins prevents an unapproved site from loading a resource. Randomizing the address makes a catalog’s shared identifier insufficient to find it. Blocking the scanning script stops a particular detector from running. Each defense has a different failure condition.
Firefox’s installation-specific resource UUIDs make public-ID probing harder. Its ETP protections also block listed fingerprinting scripts and limit selected browser attributes. A script list cannot cover every unknown or integrated scanner, and attribute restrictions are not a promise to suppress all DOM effects. [2] [9]
Safari’s randomized-resource design was discussed in WebKit’s engineering work on page-visible URL leakage. Its newer Private Browsing design also turns off extensions with website/history access by default, while content blockers are handled differently. These are distinct protections with distinct scopes. [12] [11]
A random address is not automatically a partitioned identity. If an extension exposes the same randomized host in more than one page, observers can potentially compare that host during its lifetime. Hiding predictable addresses and preventing cross-site reuse of a leaked identifier are different engineering problems.
A VPN changes the route to a site, not the extension’s local page behavior. Clearing cookies removes stored state, not installed software. A private window may reduce exposure if fewer extensions can run there, but extensions allowed in that context and the browser’s resource-loading rules still matter. [16]
Meaningful defenses
Reduce unnecessary traces. Keep useful protection.
No configuration hides every extension effect. Start with the tools and websites that matter to your work.
Audit the tools you actually need
Review your browser’s extension manager. Remove unused tools, check their publisher and update history, and understand their requested access. An obsolete extension adds a surface without providing current value.
Constrain where tools operate
Use site-specific or on-click access where supported and practical. Review private-window permissions separately. Restricting execution can reduce page modifications, but do not assume it also rewrites the extension’s web-accessible-resource policy.
Separate sensitive work deliberately
A dedicated profile with only necessary extensions reduces accidental mixing of work, personal browsing, and sensitive research. Check sync settings so a large extension set is not automatically copied into it. Shared accounts and other fingerprint surfaces can still connect profiles.
Use browser defenses before stacking add-ons
Keep the browser updated, use its built-in tracking protections, and check site exceptions. More overlapping privacy extensions can create more page changes and compatibility problems. A content blocker’s value can outweigh its detectability; evaluate both.
Test a question, not a score
With synthetic or authorized test environments, compare a clean profile and one with a single extension. Record the browser version, extension version, permissions, mode, test origin, and detection method. Repeat after updates. A detector’s empty result is evidence about its coverage, not a certificate of invisibility.
For teams, look for extensions installed across many staff devices as well as unusual individual tools. A standardized security agent, research platform, or workflow integration may reveal organizational context even when it is not personally unique.
Extension engineering
Expose less. Assume the page can observe its own state.
Keep private assets out of web_accessible_resources. Expose only the required files to the required origins. For compatible Chromium extensions, use dynamic resource URLs and generate addresses with runtime.getURL() rather than embedding a store ID.
{
"web_accessible_resources": [
{
"resources": [
"images/toolbar-icon.png"
],
"matches": [
"https://app.example.com/*"
],
"use_dynamic_url": true
}
]
}This excerpt is not a complete manifest. Its origin restriction permits the example application, not every website. Chrome’s dynamic ID changes on browser restart or extension reload; it is not a per-request identifier. Check compatibility in every browser you support. [1] [3]
Minimize unnecessary DOM markers, page-visible extension URLs, broad CSS selectors, and unsolicited messages. Isolated worlds protect internal JavaScript variables, but not the visible changes your extension makes. Where interaction is necessary, treat the page as potentially hostile and validate the interface between page code and extension code.
Measure detectability alongside usability. A distinctive marker may serve a legitimate integration; removing it can break the feature. Document that trade-off and test with trusted and untrusted origins, private modes, and multiple versions. No single manifest option makes every behavioral effect invisible.
Common questions
What an extension fingerprint does—and does not—tell you.
Can every website see every extension?
No. Visibility depends on the browser, extension implementation, permissions, enabled state, and method used. Catalog-based scanners have finite coverage. Page behavior may reveal tools not covered by a resource catalog.
Can a site read my passwords just because it detects a password manager?
Detection is not access to the extension’s protected contents. Seeing an icon or resource is different from reading stored credentials. Credential theft would require another exposure, deceptive interaction, or vulnerability.
Does a positive result identify a person?
It can support recognition of a browser or tool configuration. Personal identification needs additional context, such as a signed-in account. A shared browser, shared deployment, or popular combination may fit multiple people.
Does navigator.plugins list browser extensions?
No. That property relates to browser plug-in information, not a general inventory of modern add-ons. Extension fingerprinting relies on other observations and should not be confused with legacy plug-in enumeration. [18]
Should I uninstall my blocker, password manager, or accessibility tool?
Consider its benefit and exposure together. A useful tool may prevent larger harms. Remove unnecessary extensions, constrain access where possible, and evaluate the actual method you need to defend against.
Will a browser fingerprinting test tell me whether extensions are hidden?
Only if it explicitly tests extension-related methods—and even then only within its coverage. A canvas score or an unchanged identifier does not explain which extensions were observable.
Keep learning
Follow the evidence.
Sources and technical references
Research results describe the browsers, extensions, and samples tested at the time. Product documentation describes mechanisms rather than a guarantee that every extension uses them correctly.