Developer tool
Website Tech Stack Detector
Find out what a website is built with: CMS, frameworks, analytics, CDN, hosting and ecommerce, detected from headers, HTML, scripts and the generator tag.
Our server fetches the one page you enter, matches it against a rule list, and shows the result. Nothing is stored.
How to use the website tech stack detector
What is this website built with?
Agencies, developers and marketers often ask the same question about a site: which CMS, which framework, which analytics and where is it hosted? This tool answers it by reading the clues a page gives away.
How to use it
- Enter a public URL.
- Press Detect. The page is fetched once, with a size limit.
- Read the results grouped by category: CMS, framework, ecommerce, analytics, tag managers, CDN, hosting and server.
- Each item shows the evidence that triggered it and a version when one is visible.
Where the clues come from
- Headers: names such as x-powered-by, server, cf-ray, x-vercel-id and x-shopify-stage.
- HTML markup: known element IDs, data attributes and paths like /wp-content/ or /_next/static/.
- Script and style URLs: analytics and tag-manager snippets, widgets and libraries.
- Meta generator: many CMSs announce themselves, sometimes with a version number.
- Cookies: session cookie names that betray a framework.
Using the result
- Competitor research: see whether a rival runs on a hosted builder or custom code.
- Migration planning: list the tools your client's current site depends on.
- Sales and outreach: know the platform before you suggest an improvement.
- Security hygiene: a visible CMS version is a reason to check that it is up to date, and a leaked server version can be hidden.
Limits
Only the home page and its response are inspected. Tools loaded after consent, behind a login or via server-side calls cannot be seen, and a cached or proxied site may show the CDN rather than the origin host. The rule list covers common technologies, so very niche tools will not appear.
Next steps
If you find that a site has outdated software or slow hosting, our team can help with a rebuild or performance tune-up. Browse the related DEV3 services below.
Frequently asked questions
How does the detection work?
The page is fetched once. We then look at response headers, cookie names, script and stylesheet URLs, known markup patterns and the generator meta tag, and match them against our own rule list.
Why was a technology on the site not detected?
Detection is based on what the home page reveals. Sites can hide headers, bundle scripts under neutral names or load tools after consent. A missing result is not proof that a tool is absent.
Is the result always correct?
Matches are strong signals, shown with their evidence, but not guarantees. A site can copy a header or leave old files behind. Treat the list as a well-informed starting point.
Does it work on any site?
On public http and https pages. Private addresses are refused, only the first 1 MB of HTML is read, and pages that render everything in the browser may show little in the raw HTML.
Where does the rule list come from?
It is our own, written from documented header names, standard file paths and generator tags. It is not copied from any commercial or open fingerprint database, and it covers the most common tools rather than thousands.
Is it appropriate to scan other people's sites?
Reading a public home page is the same as visiting it once, and the tool makes one request. It does not probe for vulnerabilities, log in, or load other pages.