Fingerprinting 148 technologies from markup, headers and cookies

The Tech Stack Detective tries to figure out what a site was built with. It basically reads a page the way an uninvited guest reads a hallway: the labels people leave on things. Here is what it actually looks at, and where the results get a little fuzzy.

Three kinds of evidence, in order of trust

Response headers are the strongest signal, because the server sends them deliberately and the developer rarely thinks to hide them. Server, X-Powered-By, Via, X-Generator and such will happily tell you about a proxy, a framework or a CMS.

Cookie names are next. Frameworks name their cookies distinctively, and with a cookie like wordpress_logged_in, you can be pretty sure you're looking at a WordPress site. Only the names are read — the values are never shown and never stored, because a cookie value is often a session token and there is no reason to look at it.

Markup patterns are the weakest, and the source of nearly every false positive. A <script> path with react in it, a well-known asset directory, a generator meta tag, a CDN hostname: each is a decent hint but none is proof.

What gets in the way

• Minified and bundled assets. When everything is compiled into app.4f2c1b.js, the giveaway filenames disappear.
• Single-page applications. If the framework renders after load, the raw HTML has nothing in it to fingerprint. The detector reads what the server sends, not what a browser would end up showing.
• Deliberate hygiene. Security-conscious setups strip the identifying headers, and they are right to.
• Shared infrastructure. A CDN in front of everything means many sites look identical at the header level.

What it reports, and how to read it

The detector holds about 148 signatures across 18 categories: CMS, JavaScript frameworks, UI libraries, web servers, analytics, ad networks, CDNs, hosting, fonts, marketing and payment tools, and so on. A hit means "a signal that usually indicates this", never "this is confirmed". The page says so in its own FAQ, and the honest reading is: use the output as a starting point, then view the page source and confirm what matters.

The plumbing

Your browser is not allowed to read another site's response headers. That rule is called CORS and it exists to stop exactly this kind of snooping. So my tool asks the site's own server to do the fetching instead. The server is fussy about it: it will only fetch ordinary public addresses (never localhost, never a machine on a private network), it checks each redirect before it follows it, it stops reading after 2 MB, and it gives up after 12 seconds. It lifts out the headers, cookies and markup, then throws the page itself away. Nothing is stored.

None of this is available on a copy of my site served without the server behind it. So it won't work for a static export, or a mirror, or if the files opened straight from disk. If this happens, the tool will falls back to a public relay, a middleman service that fetches the page for it, and it shows a banner explaining this. That banner is not just so you don't steal my code: a relay is a third party seeing your request, which is a genuinely different privacy story. The warning is not decoration. On the live site you should never see this banner.