Every web technology we detect, with versions
Each card opens a canonical page with the official description, the latest release, the detection signals and a structured walkthrough for reproducing the detection in DevTools. Beyond the curated lists below, any Wappalyzer-known technology, npm package or WordPress plugin slug resolves on demand.
What this catalogue covers
Sourcemap Explorer detects roughly three kinds of things on a web page: frameworks and platforms (React, Next.js, Shopify, WordPress, Cloudflare, Stripe), npm packages bundled into the JavaScript output (TanStack Query, Zod, Radix UI, date-fns, the long tail of internal helpers), and WordPress plugins loaded from /wp-content/plugins/<slug>/. Each entry in the lists below opens a per-item page that pulls real data from the upstream source — the npm registry for packages, the wordpress.org plugin directory for plugins, and the community-maintained Wappalyzer fork for frameworks — and renders it alongside Sourcemap Explorer's detection methodology.
Each real stack item has exactly one canonical URL. Several Wappalyzer entries are fundamentally the same item as a wp.org plugin (Yoast, WooCommerce, Elementor, Rank Math, Akismet, Contact Form 7) or as a canonical npm package (next, react, vue, svelte, preact). For those we 301-redirect /stack/tech/<name> to the canonical /stack/wordpress/<slug> or /stack/npm/<pkg>. No duplicate content; one URL per real thing.
How Sourcemap Explorer detects each kind
Frameworks
Combines the vendored Wappalyzer fingerprint database (response headers, cookies, asset URL prefixes, runtime globals, DOM markers) with sourcemap path matching against node_modules/<framework>/. The framework version comes from the embedded package.json — exact semver, patch number included.
npm packages
Reads the JavaScript sourcemap's sources[] array for node_modules/<package>/ paths plus the embedded package.json contents in sourcesContent[]. Every bundled package gets surfaced — including the long tail no fingerprint database catches.
WordPress plugins
Enumerates every /wp-content/plugins/<slug>/ URL on the page and pulls the version from the ?ver= cache-buster query string. Every plugin loading on the page is surfaced by slug — known and unknown.
Frameworks & services
Curated from the Wappalyzer catalogue (~7,500 technologies). The extension surfaces these in the popup's Stack tab.
Programming languages
Inferred from headers, source extensions, sourcemap paths and runtime signals. Languages with a canonical npm artefact (TypeScript, Sass, Bun) inherit the latest release straight from the registry.
npm packages
Detected via embedded package.json, node_modules/ paths and import statements in the original sources.
WordPress plugins
Enumerated from /wp-content/plugins/<slug>/ in script URLs. Metadata pulled from the wp.org plugin directory.
Related sections of the site
Detection deep dives
Long-form guides for the most-detected frameworks (Next.js, React, Vue, Nuxt, Svelte, WordPress, Shopify, Tailwind) with detection signals, version extraction, in-the-wild patterns and FAQs. /detect →
Practical guides
Step-by-step workflows for downloading sourcemaps, identifying the CMS behind a site, finding the exact version of an npm package, listing every JavaScript library a site uses, and more. /how-to →
Alternative tools
How Sourcemap Explorer compares against Wappalyzer, BuiltWith, WhatRuns, SimilarTech, W3Techs, Netcraft and NerdyData on pricing, depth and per-page accuracy. /alternatives →
FAQ
How is this stack catalogue different from Wappalyzer's?
Wappalyzer's catalogue is a fingerprint database — names, categories and matcher rules. The Sourcemap Explorer catalogue rendered here merges that data with the npm registry (for exact versions, peer dependencies and READMEs of bundled packages) and the wp.org plugin directory (for installs, ratings, screenshots and FAQs of WordPress plugins). The result is a single canonical page per real stack item rather than three separate sources you have to cross-reference yourself.
Why are some pages much richer than others?
Page depth scales with what the upstream sources publish. Tech pages with a clear npm-package mapping (Next.js → next, React → react) inherit the full README and version history; npm pages whose GitHub repo exposes a README inherit that body; WordPress plugins with detailed wp.org sections (installation, FAQ, changelog) inherit those. Pages without those upstream signals lean on the structured detection-methodology, common-pairings and FAQ sections that ship in every template — never less than ~1000 words of unique content per slug.
How do I detect a technology not listed here?
Anything Wappalyzer's database knows about resolves automatically at request time, even when it's not in the curated lists. Type the slugified rule name into the URL (e.g. /stack/tech/<your-tech>) and the page renders if the technology is in the database. The same applies to /stack/npm/<package> for any npm registry slug and /stack/wordpress/<slug> for any wp.org plugin slug.
Is the data live or cached?
npm and wp.org data refresh every 30 days via Next.js incremental static regeneration; the underlying Wappalyzer fingerprint database is vendored in the extension and rebuilt on each landing-site deploy. Tech pages that map to npm packages are tied to the same 30-day refresh cycle for the version field. The detection signals themselves change rarely.
Why do some /stack/tech/<x> URLs redirect somewhere else?
Several Wappalyzer entries are fundamentally the same item as a wp.org plugin (Yoast SEO, WooCommerce, Elementor, Rank Math, Akismet, Contact Form 7, ...) or as a canonical npm package (next, react, vue, svelte, ...). To prevent duplicate content and consolidate ranking signals, those URLs 301 to the canonical /stack/wordpress/<slug> or /stack/npm/<pkg> page. The original /stack/tech/<x> URL stays valid forever — it just redirects.
How do I add a missing technology?
WordPress plugins and npm packages are added by the upstream registries automatically — anything published on wp.org or npm resolves on demand. For Wappalyzer-tracked frameworks and platforms, contributions go through the upstream Wappalyzer fork (enthec/webappanalyzer) which we vendor on each release. For curating the static-prerender list (the items that ship with the build), open an issue on the project's source-control host.