Technology detection
Paste a URL to find out what a site is actually built with: JavaScript frameworks and meta-frameworks, CMS and website builders, CSS frameworks, CDNs, analytics, payments, chat widgets, and security services — each match shown with the header, cookie, markup pattern, or asset URL that proved it.
Paste any public URL into the analyzer to read its raw source, run the SEO audit, grade its security headers, and detect the technologies it uses — free, with no signup and nothing stored.
Next.js, Nuxt, SvelteKit, Remix, and Gatsby are matched on their build fingerprints — __NEXT_DATA__, /_next/static/, __NUXT__, /_nuxt/, __sveltekit_, or __remixContext — while React, Vue, Angular, and Svelte are matched on DOM markers such as data-reactroot and data-v- hashes.
WordPress, WooCommerce, Drupal, Joomla, and Ghost are identified from paths like wp-content/, sites/default/files, /media/jui/, and generator meta tags. Shopify, Wix, Squarespace, and Webflow are caught through their asset hosts and data-wf- style markup.
Tailwind CSS is confirmed by counting utility-class clusters rather than trusting a single class name, so a page that merely happens to use flex is not reported as a false positive.
Cloudflare, Vercel, Netlify, Amazon CloudFront, Fastly, and Akamai are read from their send-off headers — cf-ray, x-vercel-id, x-nf-request-id, x-amz-cf-id, and x-fastly-request-id.
Google Analytics, Google Tag Manager, and HubSpot are matched on their script hosts, giving you an immediate read on what a page is measuring and who it shares data with.
Stripe, Intercom, Crisp, Drift, Algolia, Disqus, Sentry, and Google reCAPTCHA or hCaptcha are all resolved from their embedded script URLs.
Headers are the strongest signal because they are set by the server or the edge, not by the page. A server, x-powered-by, or platform-specific header frequently names the stack outright.
Cookie prefixes and names leak the platform and its plugins — a reliable fallback when markup has been minified beyond recognition.
Meta generator tags, framework root elements, and templated class names are matched against the raw HTML exactly as the server returned it, with no script execution.
Script, stylesheet, image, and link targets are scanned for library filenames and CDN hostnames, which is how a bundled React or an older jQuery build gets caught.
Every detected technology is listed with the category it belongs to and the signal that triggered the match — header, cookie, HTML markup, or asset URL — so you can verify the conclusion instead of trusting it.
We only report what the served HTML and headers actually support. Nothing is executed and nothing is inferred from a single ambiguous token, which is why the result is shorter — and more trustworthy — than a guess-heavy fingerprint database.
See at a glance which platforms a sector has standardised on, and how often a CDN or analytics suite recurs across the sites you track.
Confirm what a site actually runs — including its CMS, plugins, and edge provider — before you scope a rebuild or estimate what has to be preserved.
Establishing the framework and CDN behind a page turns “it looks broken” into a report someone can act on.
FAQ
The questions people ask most about this tool — and the limits worth knowing before you rely on it.
Every result is backed by evidence you can inspect: the HTTP header, cookie, HTML pattern, or asset URL that triggered it. Detection reads only the HTML and headers the server returns — it never executes scripts — so client-side-only libraries injected after load are not reported, and a technology is only listed when at least one concrete signal matches.
Tailwind is identified by counting a genuine utility-class cluster: at least two responsive variant prefixes such as sm: or lg: and at least eight distinct utility classes. A page that uses one or two utility names is not reported, because a single class like flex is not enough evidence to claim a framework.
Not if it leaves no trace in the delivered markup. The detector parses the raw HTML and response headers without running JavaScript, so anything added purely at runtime by client-side code will be invisible. That is the same view a non-rendering crawler gets, which is exactly what makes the result useful for SEO and security review.
They appear in the Technologies tab of the analysis, grouped by name with their categories and the evidence behind each match. The same detection also feeds the summary row at the top of the result.
No. The URL is fetched once, analyzed in memory, and discarded. No database row is created and no history is retained, so there is nothing to delete afterwards.
Related tools