Website Technology Detector

Paste a URL to find out what it runs on — CMS, framework, analytics tags, fonts, CDN and embedded services — each with the exact snippet of HTML that gave it away. Free, instant, no signup.

How detection works & how to read it

It scans the page's rendered HTML for signatures that only one technology leaves behind: a vendor hostname (cdn.shopify.com, static.hotjar.com), a framework-specific attribute (data-wf-site, ng-version, astro-island), a global that only one script sets (__NEXT_DATA__, __NUXT__, fbq(), or a generator meta tag. Every detection shows the matched snippet so you can verify it. Nothing is sent to the site beyond fetching the page — no header sniffing of other resources, no port scans. If the page is served from a platform subdomain such as *.vercel.app or *.myshopify.com, that is counted as a hosting signal as well.

It is deliberately conservative. Tailwind, for example, is only reported when the page uses several responsive-prefixed utilities and several palette utilities together — a page with a class named text-center is not Tailwind. React is reported through the frameworks built on it, because a production React bundle leaves no reliable marker of its own. The flip side is that a heavily customised or self-hosted stack will show fewer technologies than it really uses.

What to do with the results

  • Competitive research — see which CMS, e-commerce platform, analytics stack and chat or consent widgets a competitor has chosen, with evidence you can cite.
  • Auditing your own site — catch tags you forgot were installed. An abandoned Hotjar snippet or two analytics scripts loading side by side cost load time and can put you on the wrong side of consent rules.
  • Migration planning — confirm the framework and hosting a site is on before scoping a rebuild, and check the new site after launch to make sure the old tags did not come along.

Frequently asked questions

How accurate is the detection?

It is tuned for precision over recall. Every signature is something only one technology leaves in the HTML — a vendor hostname, a framework-specific attribute, a global variable only one script sets — and the matched snippet is shown so you can check it yourself. The trade-off is that a site which self-hosts its scripts, renames its asset paths, or serves everything through its own CDN will show fewer technologies than it really uses. When something is missing from the list, read that as "not detected", not "not used".

Why doesn't it detect React on a site I know is built with React?

Production React leaves almost no trace in the HTML: the data-reactroot attribute disappeared with React 18, and bundlers rename everything. React is reported when a framework built on it is found (Next.js, Gatsby, Remix) or when the page loads react-dom from a public CDN. A plain Vite or CRA build usually cannot be told apart from any other bundled JavaScript app by looking at the markup.

Can it tell what server-side language the site uses?

Only when the framework leaves a fingerprint in the page. Django's csrfmiddlewaretoken field, Rails' authenticity_token meta tag, Laravel Livewire's wire: attributes and ASP.NET's __VIEWSTATE are all detected. A bare PHP, Express or Go backend that renders clean HTML is invisible from the markup alone — that information lives in HTTP headers like X-Powered-By, which this tool does not read.

How does it work out the hosting provider or CDN?

From two kinds of evidence. Some platforms inject scripts or paths into every page — Cloudflare's /cdn-cgi/ email-decode and Rocket Loader scripts, Vercel's /_vercel/insights, Netlify's /.netlify/functions. And if the page itself is served from a platform subdomain (*.vercel.app, *.netlify.app, *.github.io, *.myshopify.com), that counts too. A site on a custom domain behind a CDN that injects nothing will show no hosting result — DNS records and response headers would be needed for that, which is outside what this tool looks at.

Is it okay to run this on a competitor's site?

Yes. It reads the same public HTML any browser downloads to display the page — the same thing you would see with View Source — and makes no requests beyond fetching the page. No login is attempted, no hidden endpoints are probed, and nothing is stored beyond a short-lived cache of the page itself.

Related tools

Redirect Chain CheckerSitemap ValidatorRobots.txt GeneratorRobots.txt Checker

Command Palette

Search for a command to run...