StackPrism identifies the tech stack behind any webpage

Four channels instead of one URL scan

Most stack-detection extensions look at the resource URLs inside the HTML. StackPrism takes a different structure and states the contrast itself: detection splits into four independent channels running in parallel. Static scanning has an injected script sweep the DOM, global variables, CSS class names, CSS variables, and meta tags as the page loads. Response header observation happens in the service worker, which listens to webRequest onHeadersReceived and captures headers from the main document, XHR calls, and iframes, along with the HTTP version. Dynamic resource monitoring uses PerformanceObserver and MutationObserver in a content script to accumulate scripts, styles, iframes, and feeds that load after the page first renders. The fourth channel scans JavaScript copyright comments: the background asynchronously fetches the head of the main bundle to identify third-party dependencies bundled into index, main, or vendor chunks. Results from the four channels are merged and deduplicated, then grouped into more than 50 categories, with explicit convergence logic for forged headers, self-referential detection, and fuzzy false positives.

Installing StackPrism in Chrome, Edge, and Firefox

The project publishes builds on the Chrome Web Store, Edge Add-ons, and Firefox Add-ons, so the store route is one click per browser. The README also documents loading from source, which matters if you want to modify rules:

git clone https://github.com/setube/stackprism.git
cd stackprism
pnpm install
pnpm run build            # Chrome / Edge
pnpm run build:firefox    # Firefox

For Chrome or Edge, open chrome://extensions or edge://extensions, enable Developer mode, and use Load unpacked to select the dist/ directory. For Firefox, open about:debugging and use Load Temporary Add-on on dist-firefox/manifest.json, or grab the .xpi produced in the release/ directory after the Firefox build. One step the README calls out for first-time installs: refresh the target page so the service worker can capture the main document response headers, since a page loaded before the extension was enabled has no observed headers.

Rules are data, not code

The rule system is deliberately data-driven: the README states that most detection changes are edits to rule JSON files, with no code touched. public/rules/index.json lists every rule file to load, page rules under public/rules/page/ handle source, DOM, resource URLs, and dynamic resources, and header rules under public/rules/headers/ handle server responses and cookies. Two special files round it out. public/rules/self-host-suppress.json implements self-referential suppression, skipping same-name detection when you are browsing the matching major site, so the extension does not report GitHub while you are on GitHub. public/tech-links.json maps technology names to official site and repository URLs, making results clickable. The build does real work here: a precompileRulesPlugin in vite.config.ts runs at the closeBundle stage and injects __hints, the top three longest literal segments per rule, plus __keywordCombined, a merged keyword regex, so the runtime matcher in rule-matcher.ts can filter candidates before running full matches.

Inside a detection rule

A rule declares a name, one of the 50-plus categories, and a matchType of regex or keyword with its patterns. The matchIn field restricts where matching happens: html, resources, url, or headers, and dynamic resources loaded after render. Two more fields carry additional signals: selectors lists CSS selectors to look for, globals names window variables to probe, and classPrefixes covers CSS class prefixes. Confidence is declared as high, medium, or low, which is what the interface shows when evidence is thin. The project ships more than 2000 rules across the categories, and the README asks contributors to run pnpm run typecheck, pnpm run lint, and pnpm run build before submitting, all three passing. Reporting a wrong detection needs no GitHub knowledge: the popup has an inaccurate-detection button that opens a pre-filled issue template, and the settings page offers a rule-contribution path.

Reading the results: categories, confidence, and forged headers

The category table spans the full stack. Frontend covers frameworks, UI libraries, build and runtime tooling. Server-side covers web servers, backend frameworks, CDNs and hosting, and languages. Content covers CMS platforms, e-commerce systems, themes, and RSS. Third-party covers SaaS, monitoring probes, AI models, third-party login, and payments. Marketing covers ads, statistics, analytics, and tag management. A security category covers HTTPS, HTTP/2, HTTP/3, CSP, and cookie consent. The README is careful about the weakest ground: backend detection is not guaranteed, because many sites strip Server and X-Powered-By headers, so backend results appear as clue plus confidence rather than fact. Forged headers get explicit treatment: when four or more identity fields are present simultaneously, the extension flags the forgery scenario, downgrades the related categories to low confidence, and attaches a warning, though a single forged header cannot be detected on its own.

Rule quality discipline

The contribution guidance doubles as a masterclass in what makes fingerprinting reliable. Prefer high-signal evidence: response headers, exclusive resource URLs, a meta generator tag, window globals, unique CSS selectors, JavaScript copyright comments, and official SDK package names. Avoid short or overly broad keywords, with the README naming spring, phoenix, column, and container as examples that match competitor discussions or generic Bootstrap and Tailwind class names. Restrict matchIn wherever possible, preferring resources, url, or headers over bare html, because matching raw HTML multiplies false positives from body text. This discipline is why the two-channel design exists in the first place: headers and URLs are cheap and precise, while DOM and globals are broad and noisy, and the confidence system is how the two worlds coexist in one result panel.

Limits worth knowing before you trust a result

Four limits come from the README cautions section. Source code search is a DOM snapshot: it reads the current outerHTML, not the original HTML the server returned, so server-side-only markers can be invisible. Chrome system pages, store pages, and built-in pages usually refuse script injection, so there is nothing to detect there. Dynamic monitoring accumulates asynchronously, so resources loading after your first look appear when you reopen the popup. And the rule base, at 2000-plus entries, moves slower than the frontend ecosystem, which is why the project treats false positives and missing frameworks as issue reports rather than defects. One structural note for redistributors: the license is CC BY-NC-SA 4.0, permitting non-commercial use and modification with attribution and share-alike terms, which rules out commercial redistribution of the rule set. The last push was on 2026-09-09, with releases from v1.3.50 to v1.3.70.

Editorial conclusion

StackPrism fits developers and analysts who want to know what a site runs without opening devtools, and who are fine treating backend findings as clues rather than facts. Do not expect results on Chrome system or store pages, and do not treat a single fingerprint as proof on a site that fakes headers. Install it from the store for your browser, refresh a target page once so the service worker catches its headers, and use the built-in inaccurate-detection button to feed wrong results back as issues.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. setube/stackprism on GitHub