ChromeSnifferPlus: a passive sniffer for the stack behind a page

ChromeSnifferPlus inspects the page you are already browsing

ChromeSnifferPlus is a browser extension, not a service and not a scanner you point at a target. Its stated purpose is to sniff the web framework and JavaScript libraries running on a website you visit, and the README describes it as an extended version of Appspector, which was itself called ChromeSniffer. The workflow is passive. You open a page in Chrome or Edge, the extension runs against that page, and it reports what it recognises. Nothing is sent to a backend and no account is required.

That shape decides who finds it useful. A developer debugging a third party widget on a customer site can open the page and get a list of candidates in seconds instead of reading minified script tags. A support engineer taking a first look at an unfamiliar property management or forum software benefits the same way. Someone doing continuous fingerprinting of many hosts at once does not, because the tool is bound to the browser session and the current tab.

The catch is that the answer comes from a signature list baked into the extension. The top level of the repository contains no rules file, no signature data and no documentation of how a match is scored, so a negative result carries less weight than a positive one.

Detection spans four layers, from jQuery to IIS

The README groups what the extension can sniff into four categories. JavaScript libraries are listed with jQuery, ExtJS and Angular among them. Web APIs are listed with Blogger and Google Analytics. Web frameworks are listed with WordPress, phpBB, Drupal, MediaWiki and codeigniter. Web servers are listed with PHP, Apache, nginx and IIS.

Grouping the results this way is the useful part, because a page can report several items at once and the categories give you a quick sense of the situation. A hit on a web framework alongside a scripting language usually points at a classic server rendered application, while a hit on a JavaScript library with no framework and no server entry points at a static or single page site. The four layers give the report structure rather than a flat list of names.

The README also says that unknown frameworks and libraries can be found, which is a claim about breadth rather than about mechanism. Nothing in the repository layout explains how an unknown technology is recognised or how confident the match is. There is no visible score, no confidence rating and no way to mark a finding as wrong from inside the extension, so the categories tell you what was recognised but not how sure the tool is.

Installation is a store listing, with no build step to run

There is no installation command for this project, because there is nothing to compile. The README gives two places to get the extension, the Chrome Web Store listing and a Microsoft Edge add-on entry. Each listing is the normal path: open the page, confirm the permission prompt in the browser, and the extension becomes available from the toolbar.

No command block appears here because none is documented. The README contains no shell command, no package name and no configuration file for installation, and the repository has no package manifest, no lock file and no build script at its top level. Loading the directory as an unpacked extension would be a developer path, but the README does not describe that route, so anyone planning to run from source should expect to work it out from manifest.json themselves.

There is one detail worth checking after installing. The extension ships a popup and an options page, so the first useful action is opening the options view, which lives in option.html, and confirming the categories you want reported. The default set of categories is not spelled out in the README.

A flat Chrome extension layout with no tooling around it

The repository's top level reads like a packaged extension rather than a development environment. It contains manifest.json, popup.html, option.html, the js/ and css/ directories, an apps/ directory, a _locales/ directory, the icon files, a screenshot/ folder, changelog.md, Privacy.md, an .editorconfig and a .gitignore.

Three things follow from that list. First, the extension appears to ship as source, with no compile step in the repository and no generated asset folder to rebuild. Second, the _locales/ directory means the interface is meant to be translated, which is a normal extension convention rather than a notable feature, but it does mean the strings you see in the popup are not the strings in the source. Third, the presence of a Privacy.md file next to a tool that inspects every page you open is the place to look for the data handling question. The README does not summarise what that file says, so it is the first thing to read rather than the last.

The changelog.md file is linked from the README as the change log, which is the only record of behaviour changes in the repository.

Six years sit between v2.9.1 and v3.0.0

The release history is short and uneven. Versions v2.9.0 and v2.9.1 arrived three days apart in July 2020, on 2020-07-20 and 2020-07-22. The next listed release is v3.0.0 on 2026-09-01, and the last push to the repository is the same day, 2026-09-01. Between those two points the browser itself changed several times, which matters because an extension that inspects page internals has to keep up with the platform it runs on.

For a user, upgrading is a store update, and there is no migration document in the repository to describe what changed in a major version bump. The changelog.md file is the only place that can answer it, and it is not reproduced anywhere else.

For a reader judging freshness, the honest summary is that the project is not dormant but it is also not a steady series of releases. One major version landed after a long quiet stretch, which tells you the recent push is a single concentrated effort rather than an ongoing maintenance cadence.

The detection method and the privacy story are both undocumented

Two things you would want before adopting this are missing from the project, and neither can be filled in by inference. The first is the detection method. The README says the extension can find unknown frameworks and libraries, and the top level of the repository shows no signature file, so the rules appear to live inside the bundled JavaScript where they are not visible as data you can read, review or extend. There is no documented way to add a technology of your own, and no false positive handling.

The second is the data handling. A tool that inspects every page you open raises an obvious question about what leaves the browser. The repository contains a Privacy.md file, which is the right place for that answer, but the README does not summarise it and the extension description does not address it either. Anyone whose browsing history matters to them has to read that file directly and check the permissions in manifest.json rather than trust a summary.

It is also worth noting what the extension is not. There is no command line interface, no programmatic output, no server mode and no documented way to run it on a headless browser.

What it gives up against the developer tools you already have

The real alternative is the browser's own developer tools, and the difference in approach is one of recognition versus inspection. The developer tools let you look at the document, the network requests and the loaded scripts, and you decide what you are seeing. ChromeSnifferPlus takes the same page and returns a named verdict, with the results grouped into libraries, APIs, frameworks and servers, which is the same information arrived at by pattern matching rather than by reading.

That trade-off has a clear shape. For a single unfamiliar page, the developer tools are enough and give you more certainty, because you can confirm a match yourself. For a page you have to characterise quickly, across many hosts, where you are not sure which signal matters, the extension wins on the naming and grouping, and it wins on the fact that it costs one store click and no configuration.

The cost of the shortcut is trust. The developer tools show you the evidence, the extension shows you a conclusion whose basis is not published. If your work depends on being able to justify the result later, that difference decides the tool.

Editorial conclusion

ChromeSnifferPlus suits developers and support engineers who need a fast read on the stack behind a page they are looking at for the first time, and it is a poor fit for anyone who needs a documented detection method, a scriptable output or a cross browser tool. Before you rely on it, open manifest.json and check the permissions the extension actually asks for, read Privacy.md to see what it claims to collect, and read the v3.0.0 entry in changelog.md to see how far the jump from v2.9.1 changed behaviour. The last push was on 2026-09-01, and the detection list is still whatever ships inside the bundle.

Frequently asked questions

Official sources

1. justjavac/ChromeSnifferPlus on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases