🔧 Technology Detector
Identify the technologies, frameworks, and libraries used by any website including programming languages, CMS, and analytics tools.
How a stack gets identified
Enter a domain and our server requests the page, then matches what comes back against known fingerprints, grouping whatever it recognises into categories. Nothing is executed - this is the served HTML and the response headers, read closely. Most software leaves marks like these without being asked to:
x-powered-by: PHP/8.2 the server admits it
<meta name="generator" ...> the CMS signs the page
/wp-content/themes/... paths give away WordPress
/_next/static/chunks/... and these give away Next.js
PHPSESSID, ASP.NET_SessionId cookie names name the runtimeTreat the list as evidence, not an inventory
- Nothing detected is not nothing used. Headers can be stripped, assets renamed and bundled, analytics proxied through a first-party path. A quiet result often means a careful team.
- Scripts injected later are invisible. Anything a tag manager loads after the page runs never appears in the HTML we fetched, which is why the marketing tags you know are on the site can be missing from the list.
- Old code lingers. A library left in a template years ago still shows up, and version numbers read out of file paths are only as honest as those paths.
- One page, not a site. A marketing home page on a
static host says nothing about the WordPress blog at
/blogor the checkout on another subdomain.
x-powered-by header advertising an exact framework version is
a free hint to anyone testing published vulnerabilities against it, and
switching it off is usually a single line of server configuration.Frequently asked questions
How can I tell whether a site runs on WordPress?
Three signs, any of which is close to conclusive: asset URLs
containing /wp-content/ or /wp-includes/, a
generator meta tag naming WordPress and its version, and a
/wp-json/ link in the head or headers from the REST API.
Hiding the first is difficult, which is why it is the reliable one.
Can I stop tools like this identifying my stack?
You can make it harder, not impossible. Removing
x-powered-by, the server version and the
generator meta tag deletes the easy answers, and a build step that
renames and bundles assets hides the paths. Cookie names, response
header order and framework-specific URL patterns remain. Treat it as
reducing noise, not as a security measure.
Why does the result look different from what I see in devtools?
Because your browser ran the page and this did not. Devtools shows everything that eventually loaded, including scripts pulled in by other scripts; this shows what the server sent in the first response. The difference is roughly the set of third-party tools loaded at runtime.