Tech stack detector and website technology checker
See what a site is built with, from its CMS and framework to its CDN, analytics, security, payments and fonts, and which business software its company uses, from Google Workspace to Jira, Zendesk and HubSpot. Every detection shows the evidence it rests on.
By using these tools you accept the Terms and the Privacy page.
How the tech stack detector works
The tech stack detector shows what a website is built with, from its CMS and JavaScript framework to its CDN, analytics, payments and fonts. It’s useful for developers sizing up a site, for researching competitors, and for site owners who want to see what their own pages reveal. Every detection lists the evidence it rests on.
What it can identify
Detections are grouped into categories such as CMS and site builders, e-commerce, static site generators, JavaScript frameworks and libraries, CSS frameworks, web servers, back-end languages, CDN and hosting, security and bot protection, tag managers, analytics, cookie consent, payments, chat, fonts, maps and site search. Web platform features are reported too: HTTP/3 (from the alt-svc header), a web app manifest, a service worker, AMP, Open Graph tags, speculation rules and preload Link headers.
When a tag exposes an account ID, such as a GTM- container or a G- measurement ID, it’s shown next to the technology. On WordPress sites, other plugins and themes are named by their folder under /wp-content/, up to 25.
How the evidence is gathered
Up to 5 redirects are followed, and every hop is validated before it’s requested. Start tags, inline scripts, inline styles and HTML comments are matched separately, so a page that only mentions a product in its text doesn’t count as using it. The host’s DNS aliases (CNAMEs) and address ranges can reveal hosts and CDNs even when the HTML doesn’t.
Many sites load their chat, analytics and marketing tags from their own JavaScript rather than the HTML. So the detector also reads up to 40 of the site’s own script files (4 MB in all), the URLs in inline scripts, and the hosts the page asks the browser to connect to early (dns-prefetch and preconnect). The script files are read in 7 seconds at most. A service that’s only referenced this way counts one confidence level lower than one the page loads, and a match on a path alone, such as /wp-content/, only counts on the site’s own addresses.
The company domain’s DNS (for www.example.com, example.com) is read for services that never appear on the page: TXT verification records, the SPF include tree (up to 10 lookups), MX hosts, the DMARC report address, and aliases of about 35 common subdomains and DKIM selectors. Shared platforms such as github.io or vercel.app are skipped, because their DNS describes the platform, not the site. These lookups start alongside the page request but wait their turn behind it and the script files, and the whole check has a 20-second limit: anything still unanswered then is reported as not checked in time.
Our server runs on Cloudflare’s network, and its requests come back with Cloudflare’s own Server and cf-ray headers even for sites that aren’t on Cloudflare. When none of the site’s addresses belong to Cloudflare, the detector asks the server again over a direct connection and reads its real headers. If that fails, the Cloudflare-added headers are removed so they aren’t mistaken for the site’s.
Warnings beyond outdated versions
- A script loaded from polyfill.io, a domain that served malicious code after a change of ownership in 2024.
- Development builds in production: React’s or Vue’s development build, or the Next.js development server.
- Debug tools left switched on, such as Laravel Debugbar, the Symfony profiler or the Django debug toolbar, which expose settings and request data to anyone.
- Werkzeug’s built-in server, which its documentation says not to use in production.
- Leftover tags for analytics, A/B testing and sharing services that have shut down, which no longer do anything and can be removed.
Reading the result
The headline names the main platform, framework, CDN or server, then counts technologies, categories and warnings. If the page answered with an error status, the headline says the detections come from an error page, which often loads less than the real site, so check a URL that loads normally. If the address returns something other than a web page, only its headers are read.
Page facts show the HTTP status, how much HTML was read, the generator tag, how many scripts are external or inline, the DNS alias chain, the addresses and the names of cookies set, followed by every response header. You can copy the list of technologies or a plain-text report, or download the full result as JSON. To see whether those headers are configured safely, run the security headers check. To see each hop a URL takes before it reaches the page, use the redirect trace.
Updated · Maintained by Liviu Tanase
Questions
How does the detector work?
Our server fetches the page once, like a browser would, and reads its HTTP headers, cookie names, meta tags, script and stylesheet addresses, HTML markers, inline scripts, comments and the host’s DNS aliases. It also reads the site’s own script files for the services they load, and the company domain’s public DNS records. Fingerprints for about 390 technologies and about 220 DNS signatures are matched against those signals. Nothing is run, and cookie values are never read.
How does it find tools like Google Workspace, Jira or Zendesk?
From the company domain’s public DNS. Verification records (such as atlassian-domain-verification or stripe-verification) show the domain was verified with a service; the SPF record names who may send its mail (Zendesk, HubSpot, Mandrill, SendGrid); the MX record shows who receives it (Google Workspace, Microsoft 365); and aliases of subdomains such as status, help, kb or DKIM selectors point at the service behind them. Mail settings and aliases are live configuration and count as high confidence; a verification record alone is medium, because it can outlive the subscription.
What do the confidence levels mean?
High means a signal only that product sets, such as a WordPress generator tag or a cf-ray header. Medium is a strong hint, such as a CSS class pattern or a file name. Low is a weak hint, such as an image borrowed from that service’s CDN. Two independent medium hints count as high. Technologies implied by another (WordPress implies PHP) are marked as implied.
Why didn’t it find something I know the site uses?
Some technologies leave no public trace: back ends behind a CDN, bundled JavaScript with renamed files, scripts a tag manager loads after the page starts, or tools that never touch the domain’s DNS. Bot protection can also answer this checker with a challenge page instead of the real one, which the result points out. A missing detection is not proof the technology isn’t there.
What are the warnings about versions?
When a version is visible, the detector flags releases with published security bugs or no more security fixes, for example jQuery before 3.5.0, Bootstrap 3 or 4, PHP 8.1 and older, Vue 2 and AngularJS. Version banners in headers such as Server: nginx/1.18.0 or X-Powered-By: PHP/8.1 are listed too, because they help attackers pick exploits.
How big a page can it read?
The first 1 MB of HTML, for up to 5 seconds once the page starts to arrive. Larger or slower pages are read up to that point rather than refused, and the result says which limit cut them off.
How long does a check take?
Usually about a second. The page has 15 seconds to arrive, redirects included, and the whole check stops at 20 seconds. The site’s own script files get up to 7 seconds and 4 MB in all. Script files or DNS lookups that hadn’t answered by then are listed as not checked in time, never as “nothing found”, so run the check again for the full picture.
Is it a free alternative to BuiltWith or Wappalyzer?
For one page at a time, yes: no account, no browser extension and no limit beyond a few checks a minute, and every detection shows its evidence. It doesn’t keep a history of sites or build lead lists, because results are never stored. For the mail side of a company’s DNS in depth, use the SPF checker and the DMARC checker.
Is anything stored?
Not by zerobounce.ai: results are never cached or saved, so every check fetches the page fresh. Cloudflare’s request logs record the request, including the address, as the privacy page explains.