What Tech Stack Does a Website Use: The Complete 2026 Detection Guide

Right-click, View Source, and you’ve seen maybe a third of what actually runs a website. The database, the internal APIs, the message queue, the admin panel nobody outside the company will ever load, all of that is invisible to your browser, and most “tech stack detection” tools quietly fill the gap with guesses rather than telling you so.

What “Tech Stack” Actually Means (and Which Layers Are Detectable)

When someone asks “what tech stack does this website use,” they’re usually asking about four distinct layers, and only some of them ever touch your browser.

The four layers: frontend, backend, infrastructure, and third-party services

The frontend is what renders in the browser: the framework, the CSS approach, the JavaScript bundler output. The backend is the server-side language and framework that generate responses, the APIs, and the business logic. Infrastructure covers where the site is hosted, which CDN sits in front of it, and how it scales. Third-party services are the bolted-on tools: analytics, payment processing, live chat, marketing automation.

Client-side vs. server-side: why the browser only tells half the story

Everything your browser receives has already been processed by the server. A Django app and a Rails app can both output HTML that looks nearly identical once rendered. The framework that assembled the response, the database it queried, and the queue it pushed a background job to all happened before a single byte reached you. That’s the honest ceiling on browser-based detection, and it’s the same ceiling every tool in this guide runs into.

The honest limit of any detection method

No tool, free or paid, can read a server’s filesystem or its database schema from the outside. Every detection method, from manually checking View Source to running a paid technographic database, is really just pattern-matching on the client-side signals a site happens to leak. Our piece on the most popular observability tools at startups makes this split explicit: it catalogs what a stack scan can surface (frontend libraries, some infrastructure hints, third-party tags) against what stays invisible no matter how good the scanner is (the actual monitoring and logging stack running behind the scenes).

The Free 5-Minute Method: What You Can Find in Your Own Browser

Before reaching for any tool, you can get a surprisingly complete picture using nothing but your browser’s built-in DevTools.

Reading View Source, Network tab, and response headers

Open View Source and scan for script tags, meta generator tags, and comments left in by build tools. Then open the Network tab, reload the page, and look at the response headers on the main document request. Headers like Server, X-Powered-By, and cache-control values often name the framework or hosting platform directly, following the conventions documented in MDN’s HTTP headers reference. Chrome’s own Network panel documentation is worth a skim if you’ve never used it beyond the basics.

Spotting frameworks from script tags, hydration markers, and cookies

React and Vue apps often leave hydration markers in the HTML, root divs with framework-specific IDs, or data-reactroot style attributes. Next.js apps typically ship a __NEXT_DATA__ script block. Cookies can hint at the platform too: certain session cookie naming patterns are strong tells for specific e-commerce or CMS platforms.

DNS, CDN, and hosting clues (nslookup, response headers, IP lookups)

Running nslookup or dig against a domain reveals its nameservers and often its CDN. Combine that with a WHOIS lookup through a registrar-neutral tool like ICANN Lookup and you can usually identify the hosting provider or CDN layer, since most CDNs (per Cloudflare’s own explainer) leave identifiable headers or IP ranges. Our cloud infrastructure deep dive walks through reading these same DNS and header signals to distinguish AWS, Azure, and GCP deployments, and what each signal does and doesn’t confirm about the underlying infrastructure.

What this method reliably catches, and what it silently misses

This method costs nothing and takes minutes, but it’s manual, and it misses anything a site deliberately obfuscates (minified bundles with no framework fingerprints, generic server headers, custom-built platforms with no public signature).

Detecting the Frontend Framework and E-Commerce Platform

Once you’ve done the manual pass, the next step is recognizing the specific footprints of the frameworks and platforms you’ll encounter most often.

Fingerprinting React, Vue, Next.js, and Angular from the rendered page

Each major frontend framework leaves a distinct trail. React apps generally mount into a single root div and, in dev builds, expose React DevTools hooks. Vue apps often carry v- prefixed attributes before they’re stripped in production. Next.js, per the patterns described in the Next.js documentation, embeds a JSON payload for hydration that’s easy to spot once you know to look for it. Angular apps typically retain ng- prefixed attributes and a recognizable bootstrap pattern, as outlined in official framework references like React’s own docs. Our breakdown of companies using React in 2026 is a useful worked example of what that footprint looks like across real production sites, not just demo apps.

Identifying Shopify, WooCommerce, and other commerce platforms

E-commerce platforms are usually the easiest layer to fingerprint because they leave consistent, platform-specific asset paths, checkout URL patterns, and admin routes. Shopify stores, as Shopify’s own developer documentation confirms, load assets from a predictable CDN pattern and expose a recognizable checkout flow. WooCommerce, built on top of WordPress per WooCommerce’s official site, inherits WordPress’s own detectable markers plus its own plugin asset paths. Our analysis of companies using Shopify shows how consistent these signals are once you know what to search for, even across very different storefront designs.

Reading analytics and tag-manager snippets

Analytics and tag-manager scripts are some of the loudest signals on any page, since they’re rarely minified into obscurity the way core app code is. Google Tag Manager containers, tracked through Google’s support documentation, are visible as a distinct script block with a container ID you can look up. Our guide to the most popular analytics tools by company size breaks down which snippets correlate with which company stage, which is often a faster tell about a company’s maturity than the frontend framework itself.

Browser-Extension Detectors: Wappalyzer and the Alternatives

Manually reading source and headers works, but it doesn’t scale past a handful of sites. That’s where signature-based browser extensions come in.

How signature-based detectors work, and where they get it wrong

Tools like Wappalyzer maintain a library of known signatures (specific script paths, header patterns, HTML markers) and match a page against that library on load. The approach is fast and free for casual use, but it inherits every limitation of manual detection, plus a new one: a signature that’s slightly out of date, or a technology that changed its fingerprint in a recent release, produces a confident-looking wrong answer instead of an honest “unknown.”

Wappalyzer’s blind spots and false positives

Because detection is signature-matching rather than actual introspection, heavily customized or white-labeled platforms frequently get misidentified, and sites using server-side rendering with minimal client-side markers can return sparse or empty results. Legacy technologies that have been rebranded or forked can also trigger false positives against the original signature.

Faster, more accurate alternatives for one-off lookups

For a single lookup, dedicated lookup tools that combine multiple detection methods (headers, DNS, rendered DOM, and a maintained technology database) tend to outperform a browser extension relying on client-side signatures alone. Our detailed comparison of Wappalyzer alternatives walks through the accuracy trade-offs between signature-based extensions and server-side lookup tools, including where each approach still falls short.

Scaling Up: Lookup Databases for Bulk and Historical Data

Once you need to check more than a handful of domains, or need to know when a company switched platforms, single-site tools stop being practical.

When a single-site check isn’t enough: bulk and list-building use cases

Sales teams building prospect lists filtered by technology, recruiters vetting a batch of employers, and researchers tracking platform migrations across an industry all need bulk lookups, not one-off checks. That requires a database that’s already crawled and indexed a large number of sites, rather than a tool that scans on demand.

BuiltWith and whether its pricing is justified

BuiltWith is the best-known player in this space, with a technology database built from crawling a large portion of the web and tracking changes over time. Whether its pricing is worth it depends heavily on use case: for occasional bulk lookups, the cost can be hard to justify, while for teams running technographic lists as a core part of sales or research workflows, the historical data can be genuinely differentiating. Our breakdown of BuiltWith pricing walks through what each tier actually unlocks.

Cheaper databases that cover the same technographic ground

Several alternatives cover overlapping technographic ground at a lower price point, though usually with a smaller crawl footprint or shorter historical window. Our roundup of 7 best BuiltWith alternatives compares coverage, export formats, and pricing tiers directly.

Get the Full Stack Behind Any Website, Free

If you just want an answer for a specific domain right now, you don’t need to run through the manual checklist above every time.

Look up a domain on StackWho

Enter any domain and get back the detected frontend framework, hosting and CDN signals, analytics and marketing tags, and e-commerce platform where applicable, pulled together in one place instead of across five browser tabs.

Export a technology-filtered company list

Beyond single lookups, you can filter by specific technology (say, every company on Shopify in a given industry) and export the list, which is the bulk use case most sales and research workflows actually need.

From single-site curiosity to a repeatable research workflow

A huge share of single-site lookups come from people vetting a potential employer before an interview. If that’s you, our guide on how to research a company’s tech stack before applying turns a one-off lookup into a structured pre-interview checklist.

Why You Still Can’t See the Backend, Database, or Internal Tooling

No matter how good your detection method, there’s a hard line between what a stack scan can surface and what a company actually runs in production.

Server-side languages, databases, and queues leave no browser footprint

The programming language handling a request, the database storing the data, and any message queue or background job system involved never send anything identifiable to the browser. A response header might hint at a web server, but it says nothing about what’s generating the data behind it.

Why “detectable stack” doesn’t mean “real stack”

A detected stack is a snapshot of client-facing signals, not an audit of the company’s actual engineering choices. Two companies can show an identical detected frontend and CDN while running completely different backends, databases, and internal tooling. Treating a detection tool’s output as the full picture is the single most common mistake people make with this kind of research.

Inference tactics: job posts, engineering blogs, GitHub, and status pages

When the backend actually matters (evaluating a company as an employer, or assessing a vendor’s technical maturity), the better signals live outside any scanner. Job postings frequently list the exact backend languages and databases a team uses. Engineering blogs and public GitHub organizations often describe infrastructure choices directly. Public status pages sometimes name specific cloud regions or services. Our piece on what the detectable stack actually shows is built entirely around this distinction: which signals a scan can surface, and which require reading what the company has written about itself.

Turning a Single Lookup Into Ongoing Research

A single detection query answers a single question. Most real use cases need more than that.

Building a repeatable competitive-analysis workflow

Rather than re-running ad hoc lookups every time a question comes up, it’s worth setting up a standard checklist: which layers to check, which tools to use for each, and where to log the findings so they’re comparable across companies later.

Detecting stack changes over time as buying or hiring signals

A company migrating its frontend framework, switching CDNs, or adding a new analytics platform is often a leading indicator of a broader initiative, whether that’s a funding round, a hiring push, or a vendor switch. Tools with historical crawl data are what make this kind of change detection possible at all, since a single point-in-time lookup can’t show a trend.

Choosing the right tool for your specific goal (hiring, sales, diligence)

A job seeker vetting one employer needs a five-minute free lookup. A sales team building a prospect list needs bulk export and filtering. An investor doing technical diligence needs historical data and change tracking. Our competitive tech stack analysis framework lays out how to match the tool to the goal instead of defaulting to whichever one you already have a tab open for.

Frequently Asked Questions

Can you tell what tech stack a website uses for free? Yes, for the frontend, hosting, and third-party layers. View Source, browser DevTools, DNS lookups, and free tools like Wappalyzer or a StackWho domain lookup will get you the client-visible layers at no cost. The backend language and database generally stay invisible regardless of tool or price.

Does “View Source” show a website’s full tech stack? No. It shows the rendered HTML and whatever script tags, meta tags, and comments the server chose to send. It says nothing about the server-side language, database, or internal infrastructure that generated that HTML in the first place.

How do I find out what framework a website is built with? Check View Source and the Network tab for framework-specific markers (hydration scripts, root div attributes, response headers), or run a signature-based detector like Wappalyzer or a lookup tool that combines multiple signal types for a faster, often more accurate read.

Why can’t I detect a website’s backend language or database? Because that layer never sends anything to the browser. The server processes a request and returns HTML, JSON, or other output, but the language, framework, and database that produced it stay entirely server-side and leave no client-visible fingerprint.

Is Wappalyzer accurate for identifying a website’s tech stack? It’s reasonably accurate for common frontend frameworks and well-known third-party tools, since those have stable, well-documented signatures. Accuracy drops for heavily customized platforms, server-rendered sites with minimal client markers, and any technology that changed its fingerprint since the signature was last updated. Our Wappalyzer alternatives comparison covers where it tends to miss.

What’s the best tool to look up the technologies a website uses? For a single quick lookup, a free tool like StackWho or Wappalyzer is enough. For bulk lists, filtering by technology, or historical tracking, a technographic database like BuiltWith (or one of its cheaper alternatives) is the better fit.

The honest answer to “what tech stack does a website use” is always partial. You can reliably detect the frontend, get strong hints about hosting and CDN, and spot most third-party tools in minutes, whether by hand or with a lookup tool. The backend, database, and internal tooling stay behind the curtain no matter which tool you use, and the only way past that curtain is reading what the company has published about itself elsewhere.