How to Check If a Website Uses React, Vue, or Angular

Curious whether a slick web app is built with React, Vue, Angular, or something newer like Svelte? You can usually find out in well under a minute. The single fastest method is to install the framework's official DevTools extension and watch which one activates — but there are several reliable fallbacks for when a site is server-rendered or heavily minified. This guide covers the practical signals, from the one-click check to reading build artefacts, plus why modern rendering sometimes hides the answer.

This is a developer-focused companion to how to find out what a website is built with; here we concentrate on the JavaScript layer.

Why it is worth identifying the framework

Knowing the framework behind a site is useful in several ways. Developers evaluate how a competitor or potential acquisition built their product, and what maintaining it would involve. Job seekers and hiring managers verify the stack a company actually ships versus what its job ads claim. Engineers learning by example want to study real-world implementations in a framework they care about. And technical due diligence often starts with "what is this built on, and is that a healthy, well-supported choice?" Because frameworks leave runtime fingerprints, these questions are answerable from the outside.

The fastest check: framework DevTools extensions

Each major framework ships an official browser extension, and the simplest detection method is to let those extensions tell you. Install React Developer Tools, Vue.js devtools and Angular DevTools. When you visit a site, the relevant extension's icon becomes active and adds its own panel to developer tools — a Components/Profiler tab for React, a Vue panel for Vue, and an Angular panel for Angular. If the React icon lights up, you are looking at a React app; if none activate, the site probably is not built with these frameworks at all. It is a genuinely one-glance answer.

Console globals and hooks

When you cannot or do not want to install extensions, the Console gives quick answers. Open devtools (F12), go to the Console, and check for framework-specific globals:

• React injects __REACT_DEVTOOLS_GLOBAL_HOOK__ into the page. Note that React usually does not expose a plain window.React, so rely on the hook rather than expecting the library by name.
• Vue 3 exposes window.__VUE__, and you can often find a component instance via an element's __vue__ property in Vue 2.
• Angular exposes window.ng, and getAllAngularRootElements() returns the app's root nodes. ng.probe was the older equivalent.

These globals are reliable because they are part of how each framework wires itself into the page at runtime.

DOM fingerprints you can read without tooling

The rendered HTML itself carries tells, which is handy when you only have View Source:

• Angular adds an ng-version="..." attribute to the root application element. This is one of the most reliable single signals in all of framework detection — it names Angular and its exact version.
• Vue uses scoped-style data-v-<hash> attributes on elements when components use scoped CSS.
• React leaves a legacy data-reactroot on older apps, and on modern apps you can find React's internal __reactProps$... and __reactFiber$... keys on DOM nodes via the Elements panel.
• Next.js (React) renders a <div id="__next"> wrapper and a __NEXT_DATA__ script; Nuxt (Vue) renders <div id="__nuxt"> with a window.__NUXT__ payload.

Build artefacts in the Network tab

The files a site downloads are a strong secondary signal. Filter the Network tab by JS and read the names:

Bundle / artefact	Framework
react-dom.production.min.js, __NEXT_DATA__, /_next/static/	React (and Next.js)
vue.runtime.*, /_nuxt/, data-v- attributes	Vue (and Nuxt)
runtime.js + polyfills.js + main.js, zone.js, ng-version	Angular
hashed Vite/Webpack chunks + Svelte class hashes	Svelte / SvelteKit
q:container attributes	Qwik

The classic runtime.js, polyfills.js, main.js trio is the Angular CLI's signature output, while zone.js is an Angular dependency you rarely see elsewhere.

The meta-framework layer

Most production sites today are not "just React" or "just Vue" — they use a meta-framework that adds routing, rendering and build tooling on top:

• Next.js (React): __NEXT_DATA__, /_next/static/, <div id="__next">.
• Nuxt (Vue): window.__NUXT__, /_nuxt/.
• SvelteKit (Svelte), Remix (React), Gatsby (React, with /page-data/ and a ___gatsby root), and Astro (which ships mostly static HTML with small interactive "islands") each have their own markers.

Identifying the meta-framework is often more useful than the base library, because it tells you how the site renders and deploys, not just which UI library it uses.

Reading the framework's ecosystem

A framework rarely travels alone, and its companions are detectable too — which often tells you more about a project than the core library does. State-management libraries leave traces: Redux exposes window.__REDUX_DEVTOOLS_EXTENSION__ and a recognisable store, while Vue's Pinia or Vuex show up inside the Vue DevTools panel. Routing is usually handled by the meta-framework (Next.js, Nuxt) or by a library such as React Router, whose URL and history behaviour is familiar once you have seen it a few times. UI and styling libraries are often the easiest tells of all: Material UI scatters Mui* class names through the markup, Chakra UI uses its own chakra- prefixes, Ant Design uses ant-, and Tailwind CSS fills elements with utility classes like flex items-center gap-2. Reading these alongside the core framework gives you the real shape of the front-end stack — its data flow, its design system, its conventions — rather than just its foundation. For a competitive or hiring review, that texture is frequently the most useful part of the picture.

A note on bundlers and build tools

The build tooling is another layer worth a glance. Webpack has historically produced chunk files with numeric or named patterns plus a runtime manifest; Vite, now extremely common, emits hashed ES-module chunks under an /assets/ directory and uses native <script type="module"> tags; and newer tools such as Turbopack and esbuild have their own signatures. Published source maps (.map files referenced at the bottom of a bundle) can reveal the original folder structure and sometimes the exact dependency versions, which is a goldmine for a deep technical review. You will not always need this level of detail, but it reliably distinguishes a modern, fast-building project from an older, heavier setup — a distinction that often correlates with how actively a codebase is maintained.

Why server rendering makes this harder

The biggest reason detection sometimes fails is modern rendering. With server-side rendering and static-site generation, the server sends fully formed HTML that looks like a plain static page, and the framework only "hydrates" it into an interactive app after load. That means the initial View Source may show little framework evidence. The runtime hooks and globals still appear once the page's JavaScript runs, so checking the Console after the page is interactive — rather than reading raw source — is the fix. Aggressive minification and code-splitting can also rename or fragment bundles, which is when the DevTools extensions and console globals earn their keep.

Can you detect the framework version?

Sometimes, yes. Angular makes it trivial: the ng-version attribute states the version outright on the root element. For React and Vue the version is not usually printed in the page, but it can surface in a few places — published source maps, a version string inside a vendor bundle's banner comment, or the meta-framework's own markers (a given Next.js release implies a compatible React range, for example). Exact versions are frequently omitted on purpose, so treat a confident version read as a bonus rather than a guarantee. And resist the temptation to judge a site by a missing version number: plenty of well-maintained, fully up-to-date apps strip that information for tidiness or security, so its absence tells you nothing on its own.

Putting the signals together

In practice you rarely rely on a single clue. A typical confident read looks like this: the React DevTools extension activates, the Console shows __REACT_DEVTOOLS_GLOBAL_HOOK__, the page source contains __NEXT_DATA__ and /_next/static/ assets, and the markup is full of Tailwind utility classes. That combination tells you, without guessing, that you are looking at a Next.js (React) app styled with Tailwind — the kind of complete answer that one signal alone could never give you. The discipline of stacking two or three independent signals is what separates a reliable read from a hopeful guess.

How accurate is framework detection?

For client-rendered apps, framework detection is highly accurate — the extensions, hooks and globals leave little doubt. Angular is the easiest of the three thanks to its ng-version attribute. React and Vue are reliably detectable through their hooks and meta-framework markers. The main accuracy gaps are heavily server-rendered sites (where you must inspect the live runtime, not the source) and sites that use a framework only for isolated widgets. As always, two corroborating signals beat one.

The fast, reliable workflow

1. Watch the framework DevTools extensions — whichever activates names the framework instantly.
2. Check Console globals (__REACT_DEVTOOLS_GLOBAL_HOOK__, window.__VUE__, window.ng).
3. Scan the DOM for ng-version, data-v-, __next or __nuxt.
4. Read bundle names in the Network tab for confirmation.
5. Identify the meta-framework (Next.js, Nuxt, etc.) for the fuller picture.
6. Cross-check two signals, and inspect the live runtime rather than raw source on server-rendered sites.

Go deeper

• The complete method: how to find out what a website is built with.
• Not a framework but a builder? What website builder is this?
• Where does it run? How to find out where a website is hosted.

Want the framework, meta-framework and full stack without the manual checks? Analyse any website with StackOptic — one report, free, no sign-up.