About the Website Tech Stack Detector
Every platform leaves marks. WordPress keeps its files in /wp-content/, a Shopify store
loads from cdn.shopify.com, Cloudflare stamps a cf-ray header on every response,
and a Next.js server often signs its responses X-Powered-By: Next.js. This detector fetches the page once from our
server and checks it against 7,628 open-source fingerprints: response headers, cookies, meta
tags, script addresses, the HTML and its elements, the TLS certificate and the domain’s DNS records.
What sets the report apart is that every result shows its evidence — the exact header, cookie, script path or tag that matched, with a confidence weight — so you can check the claim instead of trusting it. Technologies implied by others (WooCommerce means WordPress, which means PHP) are labelled as inferred, and services found only in DNS are kept apart from what the website itself runs.
The honest limit: the page’s JavaScript is not executed. About 900 technologies can only be spotted from live JavaScript objects or runtime requests, so apps that build themselves in the browser may show fewer results here than a browser extension would. The fingerprints are the community-maintained enthec/webappanalyzer set (GPL-3.0), the continuation of the original Wappalyzer definitions, evaluated on our server.
Found in the domain’s mail and TXT records, not in the page. They show which email provider and SaaS tools the organisation has connected to its domain — and verification records often outlive the service, so treat these as “has used”.
Downloads up to eight of the page’s JavaScript files, four stylesheets and
robots.txt, and checks the 800-plus fingerprints that match file contents — bundler
signatures, library banners, framework runtimes. It still does not run the code: live JavaScript objects and
runtime requests remain out of reach without a real browser, and this tool does not pretend otherwise.
How the stack hangs together: each technology, what it runs on and what it brings with it — built from the fingerprint library’s own “requires” and “implies” rules. Entries marked inferred were not seen on the page; they follow from those rules.
Every technology with its version, confidence, categories, how it was found and the exact matching evidence — as a spreadsheet, or the complete report as JSON for your own tooling.
Detect a second site and line the stacks up: what both run, and what only one does. Useful for competitor research, or for checking a migration kept everything it should.
How to Use the Website Tech Stack Detector
Type a domain or paste any page address and press Detect. The headline names the primary platform — the CMS, store builder or framework the site is built on — with hosting, server language and the number of analytics and tag tools alongside. Below that, every technology is grouped by what it does, and each one lists the evidence that matched. Scanning an inner page such as a product or checkout page sometimes reveals more than the homepage, because plugins and payment widgets only load where they are used.
Where the Clues Come From
Detection is pattern matching against things a site cannot easily avoid publishing:
- Response headers.
Server: nginx/1.25.3,X-Powered-By: PHP/8.2,cf-rayfor Cloudflare,x-vercel-idfor Vercel. Often the most direct evidence, and the easiest for an administrator to remove. - Cookies.
PHPSESSID,laravel_session,_shopify_y— session cookie names are chosen by the framework, not the site owner. - Script and stylesheet addresses. Paths like
/wp-includes/or file names such asdrupal.jsand CDN hostnames give away both the platform and, often, the library version in the file name. - Meta tags and markup. The
generatortag, framework-specific attributes such asng-version(Angular) or Svelte’sdata-svelte-h, and characteristic element structures checked with real CSS selectors against a parsed page. - The certificate and DNS. The TLS issuer (Let’s Encrypt, DigiCert, Amazon), and the domain’s MX, NS and TXT records.
Confidence, Versions and Implied Technologies
Each fingerprint carries a weight. Unambiguous clues count 100%; clues another product could share count less, and independent weak clues add up to a cap of 100%. A version appears only when a pattern captured one — from a generator tag, a header or a versioned file name — and the most specific version seen wins. Some results are inferred rather than observed: finding WooCommerce implies WordPress, which implies PHP and MySQL. Those are marked, and inherit the confidence of the technology that implied them. A database is almost never visible from outside; when MySQL appears it is because WordPress requires it, not because the database was seen.
Why Some Stacks Look Thin
A single-page application that renders in the browser sends a nearly empty HTML shell, and most of its identifying detail exists only once JavaScript runs. Browser extensions see that; a server-side fetch does not. Sites behind aggressive bot protection may answer with a challenge page instead of their homepage — the report flags that, and what you then see is the protection layer (typically the CDN and firewall), not the site. Hardened sites strip version headers and generator tags deliberately, which is sound security practice: publishing an exact version tells attackers which known vulnerabilities to try.
Practical Uses
- Competitor research. Which store platform, email tool and analytics a rival uses tells you about their budget and priorities.
- Sales prospecting. Agencies and SaaS vendors qualify leads by stack — every Shopify store is a prospect for a Shopify app.
- Security hygiene on your own site. If this page can read your exact CMS and server versions, so can anyone scanning for outdated installs. Check what you leak, then check the headers with the HTTP Security Header Grader.
- Migration checks. After moving platforms, confirm the old analytics tags, fonts and plugins are really gone.
About the Fingerprint Library
The patterns are the open-source enthec/webappanalyzer project, which continued the original Wappalyzer definitions after that project went closed-source in 2023. It is licensed under the GPL-3.0 and maintained by its community; we evaluate it on our server with an engine that mirrors the original matcher’s rules for patterns, confidence, versions and implications, validated result-for-result against the original code on 40 real websites. The library version in use is shown under “What Was Checked” on every report.
Looking at the infrastructure rather than the software? The DNS Lookup shows every record behind a domain, the SSL Certificate Checker reads the certificate chain, and the Website Privacy X-Ray lists the third-party trackers a page reports visitors to. Browse every Dev & Tech tool.
Frequently Asked Questions
How can you tell what a website is built with?
Almost every platform leaves fingerprints. WordPress serves files from /wp-content/, Shopify stores load scripts from cdn.shopify.com, Laravel sets a laravel_session cookie, servers announce themselves in headers such as Server and X-Powered-By, and many systems write a generator meta tag. This tool fetches the page and checks it against a public library of more than 7,600 such fingerprints, then shows you exactly which clue matched for each result.
Why does it miss some technologies that a browser extension finds?
Because it reads what the server sends and does not run the page's JavaScript. Extensions such as Wappalyzer also inspect live JavaScript objects and the network requests a page makes after it loads. About 900 of the 7,628 technologies in the library can only be recognised that way, so a single-page app that assembles itself in the browser can show fewer results here. What this tool does find, it can prove.
What does the confidence percentage mean?
Each fingerprint carries a weight. A strong clue, such as a generator tag reading WordPress 6.6, counts 100 percent on its own. A weaker one, such as a cookie name another product could also use, might count 50 percent, and two independent weak clues add up. Technologies inferred from another one, like PHP from WordPress, inherit the lower of the two confidences.
Why does the report list services like Google Workspace or Microsoft 365?
Those come from the domain's DNS records, not from the web page. Mail routing records and TXT verification strings reveal which email provider, and which SaaS tools, an organisation has connected to its domain. They are listed in their own section because they describe the company, not the website, and verification records are often left behind after a service is abandoned.
Can a website hide what it is built with?
Partly. Removing the Server and X-Powered-By headers, stripping the generator tag and renaming asset folders defeat the easiest checks, and a CDN or firewall in front of the site hides the origin server. The deeper patterns, such as a framework's characteristic markup or file naming, are much harder to scrub completely. A bot-check page in front of the whole site hides almost everything, and the report says so when it meets one.
