Tech Stack Detector
Detect 655 technologies across 31 categories, incl. AI builders (v0, Lovable), code assistants (Claude, Cursor), BaaS (Supabase, Firebase), feature flags and realtime. 4-source scan: HTML + headers + cookies + DNS.
What this tech stack detector finds
This tech stack detector checks four data sources at once: the page HTML, the HTTP response headers, cookies and DNS records. The HTML comes from a headless browser where possible, so scripts injected by JavaScript show up too, with the raw source as fallback when rendering fails. Coverage is 655 signatures in 31 categories: CMS, analytics, tag managers, consent tools, SEO plugins, A/B testing, frameworks, CDNs, hosting, domain verifications, Backend-as-a-Service (Supabase, Firebase, Convex), feature flags (LaunchDarkly, Statsig), booking tools (Calendly, Cal.com), realtime (Pusher, Liveblocks), AI site builders and code assistants (v0, Lovable, Claude, Cursor) and CSS frameworks (Tailwind, UnoCSS, Panda).
Was the site built with AI?
A fair question now that AI site builders (v0.dev, Lovable, Bolt.new) and AI code assistants (Claude Code, Cursor, Copilot) ship real production sites. The tool looks for two kinds of evidence: direct builder signatures (v0 deployment markers, Lovable hostnames, explicit HTML comments like <!-- generated with Claude -->) and heuristic indicators (shadcn/ui + Radix + lucide-react stack, unusually long Tailwind utility chains, AI-typical marketing phrasing). The "AI Build Signals" panel marks an explicit signature as a detection, two or more heuristics as "likely AI-built parts" and a single one as a weak signal. A skilled human using shadcn/ui matches the same heuristics, so treat them as "maybe" unless an explicit attribution backs them up.
Why four sources matter: an HTML-only scanner sees scripts loaded via <script src>, but misses what's in response headers (CDN, hosting, server stack) and DNS records (SaaS integrations like Google Workspace, Microsoft 365, Stripe). Cookies add one more layer: the names the server sets in Set-Cookie, plus names written by inline document.cookie calls. Each detection shows source badges (HTML, HDR, CK, DNS) so you know how it was found.
Why does it show Cloudflare for a site hosted on Netlify/Vercel?
Because Cloudflare sits in front. When a DNS record is proxied through Cloudflare (the orange cloud), Cloudflare terminates the TLS connection, sets its own Server: cloudflare and CF-RAY headers, then fetches from Netlify or Vercel behind the scenes. Most of the host's other headers still come through, x-vercel-id for example, so the scan often lists both.
The tool only counts those headers when the site's hostname resolves to Cloudflare's IP addresses. That check matters: the scanner itself runs on a Cloudflare Worker, and a Worker's requests come back stamped with Server: cloudflare and a CF-RAY for any site. Scans before 30 September 2026 read those stamps as the site's own and showed Cloudflare almost everywhere. For a site outside Cloudflare the tool now reads the real Server header straight from the server, which is where nginx, Apache and LiteSpeed come from.
Privacy & Consent audit: what does it actually check?
If a consent manager is detected (Cookiebot, OneTrust, Usercentrics, Borlabs, etc.) and tracking scripts are also on the page, the tool checks whether any tracker loader appears BEFORE the CMP script in the HTML source. That order is the usual sign that tags fire before the visitor has consented. It's a static check of the source, so runtime behavior (Consent Mode v2 default state, what actually fires on load) still needs a look at the Network tab in Chrome DevTools.
How accurate is version detection?
Versions are extracted from three sources, in order of trust: the <meta name="generator"> tag, explicit regex patterns tuned per tool (like wp-emoji-release.min.js?ver=X.Y.Z for WordPress core), and a generic name-at-version fallback. WordPress, jQuery, Elementor, Next.js and React have version thresholds. Anything below them gets a ⚠ outdated flag, which is useful for security audits.
Tech stack detector vs. Wappalyzer vs. BuiltWith
Wappalyzer's browser extension runs inside your browser, so it sees executed JavaScript that a fetched page can hide. BuiltWith keeps historical data going back years. This tool needs no install: it renders the page in a headless browser where it can, adds DNS records, and puts a consent-order check and a GEO readiness mini score on top. For a one-off competitor lookup it's fast. For history, use BuiltWith.
Is using a tech stack detector legal?
Yes. The HTML and DNS are served publicly to anyone who requests them. What you shouldn't do is crawl at scale or redistribute scraped fingerprint databases. The detection itself is fair game.
Explore more tools
Meta Tag Analyzer
Full meta tag audit for any URL.
Crawler Access Checker
Check AI & search crawler access.
Link Analyzer
Internal/external link analysis.
Security Headers
Check HTTP security headers and server config.
PageSpeed Insights
Full Lighthouse audit with Core Web Vitals.
FAQ
Lumina shows analytics, CMS, consent tools, and SEO plugins automatically — on every page, for free.
Add Lumina to Chrome — Free