You visit a modern website and notice fast page updates, interactive components and an app-like interface. It is natural to wonder whether React is running behind it.
Sometimes React is easy to detect. Other times, a production build can hide nearly every obvious clue.
This happens because React applications are commonly bundled, minified, server rendered or built through frameworks such as Next.js. A website can also use React for only one part of the page while the rest is built with another technology.
That means reliable React detection requires more than searching the source code for the word React.
In this guide, you will learn how to detect React using DOM clues, JavaScript bundles, React DevTools and runtime signals. You will also learn how to distinguish plain React from Next.js and why a page that looks like static HTML may still be powered by React.
For a quicker first check, you can also enter the domain into the WebBuildFinder website technology detector and then verify the result manually.
What Is React?
React is a JavaScript library used to build interactive user interfaces from reusable components.
A React application can be rendered entirely in the browser, generated on the server, generated during a build, or combined with a framework such as Next.js.
Because React can be used in several different ways, there is no single public fingerprint that appears on every React website.
React Detection Methods
The most reliable way to identify React is to combine several independent clues.
You should not assume that a website uses React because of one JavaScript file, one DOM attribute or one third party widget.
A good detection process usually includes:
- Inspecting the rendered DOM
- Checking JavaScript bundles
- Using React DevTools
- Looking for React runtime patterns
- Checking for framework specific signals
DOM Clues
React does not normally add a simple attribute such as data-react="true" to every component.
This makes DOM based React detection less straightforward than detecting some other technologies.
Look for an Application Root
Client rendered React applications often start with a relatively simple HTML container.
You might find something similar to:
or:
React JavaScript then takes control of that element and renders the interface inside it.
The name root is a common convention, but it is not required.
A developer can mount React into any DOM element.
Finding:
therefore does not prove that React is being used.
Vue, Angular, custom JavaScript and other applications can use similar containers.
Compare Page Source With the Rendered DOM
This technique can be useful for older or purely client rendered React applications.
First open View Page Source.
Then compare it with the Elements panel inside browser developer tools.
If the original HTML contains a nearly empty application container while the rendered DOM contains a complete interface, JavaScript is generating much of the page.
React is one possibility, but you still need additional evidence before reporting it.
Server Rendered React Looks Different
Modern React applications do not need to start with empty HTML.
React supports hydration, where the server sends already rendered HTML and React attaches its interactive behavior after the page loads.
As a result, a React website can have complete text, navigation, images and links visible in the original HTML source.
This is one reason DOM inspection alone is no longer enough for reliable React detection.
JavaScript Bundles
JavaScript analysis is usually one of the strongest methods for finding React.
Open browser developer tools and select the Network tab.
Reload the page and filter requests by JavaScript.
You may see files such as:
Modern build systems often give these files hashed names, so the filename itself may not reveal the framework.
Search Inside the Bundles
Open JavaScript files and search for terms such as:
Finding several of these patterns in actively loaded application code can provide strong React evidence.
Modern React applications can initialize client rendered interfaces with createRoot, while server rendered applications can use hydrateRoot to attach React to HTML that already exists on the page.
Look for React Packages
Depending on the build configuration, bundled code may still contain references such as:
These can be useful fingerprints.
However, minification and tree shaking can change what remains visible in a production bundle.
Source Maps Can Help
Some websites expose JavaScript source maps.
When available, source maps can reveal original module names and dependencies more clearly than the minified production file.
You might find references to packages such as:
Many production websites disable public source maps, so this method will not always be available.
Make Sure the React Code Belongs to the Main Website
This is important.
A website might contain a chat widget, booking form, advertising component or review system built with React.
Finding React inside that third party widget does not prove the main website itself is a React application.
Check which domain loaded the JavaScript and which part of the page it controls.
React DevTools
React DevTools is one of the easiest ways to verify React when the application exposes enough information to the browser.
The browser extension adds React specific tools to developer tools.
When React is detected, you may see panels such as:
- Components
- Profiler
The Components panel can show the React component tree used by the application.
Why React DevTools Is Useful
Instead of trying to identify React from CSS classes or visual design, DevTools works with React's runtime.
If it successfully displays the component tree for the main application, that is very strong evidence that React is being used.
What If React DevTools Shows Nothing?
Do not immediately conclude that React is absent.
Detection can become more difficult because of:
- Production optimization
- Framework architecture
- Server rendered components
- Cross-origin content
- Third party embedding
- Unusual application configuration
Use DevTools as one detection method rather than your only test.
Framework Specific Globals
JavaScript frameworks and their debugging tools can sometimes expose runtime objects or browser globals.
These can provide additional clues, but global variable detection should be treated carefully.
Older React Detection Methods
Older tutorials sometimes recommend checking for variables such as:
in the browser console.
This may work on websites that load React globally from a script tag.
It often fails on modern applications.
Applications built with Vite, Webpack, Next.js and other bundlers commonly use ES modules and do not need to expose React as:
Therefore, running:
and receiving undefined does not mean the website is not using React.
React DevTools Runtime Hook
React development tooling can use runtime hooks inside the page.
You may encounter references related to React DevTools while investigating JavaScript execution.
These can be useful supporting evidence, but they should not be your primary React detection method because browser extensions and debugging tools can influence the page environment themselves.
Framework Globals Are Supporting Evidence
The safest approach is to combine runtime clues with:
- JavaScript bundle evidence
- React DevTools
- Framework asset patterns
- Application behavior
This reduces the chance of reporting a false positive.
React vs Next.js
React and Next.js are closely related, but they should not be reported as if they are the same technology.
React provides the component and rendering model.
Next.js is a framework built around React that adds features such as routing, server rendering, static generation, data handling and application architecture.
A website can use React without using Next.js.
A Next.js website, however, uses React as part of its application stack.
Look for Next.js Assets
One of the strongest Next.js fingerprints is the asset path:
JavaScript and CSS chunks commonly appear under paths such as:
Those files may also be delivered through a CDN while keeping the /_next/ path.
Check for __NEXT_DATA__ on Pages Router Sites
Some Next.js websites using the Pages Router include serialized page information in an element identified as:
This can be a strong Next.js clue when present.
However, modern Next.js applications using the App Router work differently, so you should not require __NEXT_DATA__ before identifying Next.js.
React Without Next.js
A plain React project may instead be built with:
- Vite
- Webpack
- Parcel
- A custom build system
In that situation, React runtime evidence may be visible while /_next/ resources are completely absent.
When a Detector Shows React and Next.js
This is normally correct rather than duplicate reporting.
You can think of the stack as:
- React: UI library
- Next.js: React framework
This is similar to detecting Vue together with Nuxt.
React vs Static HTML
A common misconception is that a website with fully rendered HTML cannot be a React site.
That is no longer true.
React supports both client rendering and hydration of server generated HTML.
Client Rendered React
A traditional single page React application might initially return something simple such as:
JavaScript then builds the interface after the page loads.
In this situation, comparing View Source with the final DOM can provide useful clues.
Server Rendered React
A server rendered application can send complete HTML before React runs in the browser.
Visitors can therefore receive headings, paragraphs, images and navigation directly in the initial document.
React can then hydrate that HTML and make the page interactive.
Static React Sites
React frameworks can also generate static HTML during the build process.
The final page may look like a normal static website when you view its source.
JavaScript then enhances or hydrates the page after loading.
This makes visual comparison between React and traditional HTML unreliable.
Static HTML Can Also Load JavaScript
The opposite assumption is also dangerous.
A traditional HTML website can load large JavaScript files without using React.
Interactive menus, sliders and forms do not automatically mean a site is React based.
You need framework specific evidence.
Why React Can Be Difficult to Detect
React detection sounds simple until you examine a modern production website.
Several factors can hide or weaken its fingerprints.
Production Minification
Production JavaScript is commonly minified.
Readable function names and variable names may disappear or become extremely short.
This can remove many clues that would be obvious in development code.
Bundling
React can be combined with dozens of other dependencies into the same JavaScript bundle.
Instead of seeing a separate file named:
you may see only:
Server Rendering
Server rendered React pages arrive with real HTML.
This means searching for an empty root element is no longer a dependable strategy.
React Server Components
Modern React frameworks can execute some components primarily on the server.
Not every component therefore needs to ship its full JavaScript implementation to the browser.
This can reduce the amount of obvious client-side React code available for inspection.
Partial React Adoption
A website does not need to be built entirely with React.
React can be mounted into individual sections of an existing website.
For example, a traditional server rendered site could use React only for:
- A product configurator
- A search interface
- A comments section
- A shopping cart
- A dashboard
React's own client API supports creating separate roots for different areas of a page.
Third Party Widgets
A non-React site can still load React through:
- Chat widgets
- Review applications
- Booking tools
- Payment widgets
- Embedded SaaS products
A technology detector needs to distinguish between React being used by the main application and React appearing only inside a third party component.
Framework Abstraction
Frameworks such as Next.js can manage React initialization internally.
You may never see a straightforward application file containing:
even though React powers the site.
Common React Detection False Positives
Before reporting React, watch for these common mistakes.
React Appears in an Unused File
A website can contain old JavaScript files that are no longer loaded.
Check the Network tab to confirm that the suspected React bundle is actually requested by the current page.
A Third Party Widget Uses React
If React appears only inside a customer support or booking widget, do not automatically classify the main website as React.
The Site Has a Root Element
An element called:
is not enough.
Many JavaScript applications use a root container.
The Website Feels Like a Single Page Application
Fast navigation and dynamic updates are not unique to React.
Vue, Angular, Svelte and custom JavaScript can create similar experiences.
A JavaScript Bundle Contains the Word React
Check where the reference comes from and whether the code is executed.
A dependency, widget or old library can create misleading matches.
How to Verify React Before Reporting It
For stronger detection, try to find at least two or three independent signals.
A useful verification process is:
- Run a technology scan
- Inspect active JavaScript bundles
- Search for React runtime references
- Check React DevTools
- Look for Next.js or another React framework
- Confirm that React belongs to the main application
A result supported by several clues is much more reliable than a single string match.
Test a Website With WebBuildFinder
Manually inspecting minified JavaScript, browser globals and framework assets can take time.
For a faster first check, enter the domain into WebBuildFinder.
WebBuildFinder can help investigate publicly detectable technologies across categories such as:
- Frontend frameworks
- JavaScript libraries
- CMS platforms
- Ecommerce platforms
- Analytics tools
- CDNs
- Marketing technologies
- Security services
If React is detected, you can then use the manual methods in this guide to verify whether React powers the main website or only a smaller embedded component.
For related guides, read how to detect Vue.js and Nuxt.js or our broader guide on how to find out what technology a website uses.
Frequently Asked Questions
How can I tell if a website uses React?
Check its actively loaded JavaScript bundles for React and React DOM runtime patterns, use React DevTools, and look for framework clues such as Next.js assets. Use more than one signal because React can be bundled, minified or server rendered.
Does div id root mean a website uses React?
No. A root element is commonly used by React applications, but other JavaScript frameworks and custom applications can use the same structure.
Can React be detected with React DevTools?
Often, yes. React DevTools can display Components and Profiler panels for React applications when the runtime can be inspected. It is a strong verification method but should not be your only detection technique.
How can I tell React from Next.js?
Next.js uses React but adds recognizable framework infrastructure. Look for assets under /_next/ and other Next.js specific patterns. React without these signals may be a plain React application or use another React framework.
Can a static looking website use React?
Yes. React applications can be server rendered or statically generated and then hydrated in the browser. Complete HTML in View Source therefore does not rule out React.
Why can React be difficult to detect?
Production bundling, minification, server rendering, React Server Components, partial React adoption and third party widgets can all hide or complicate React fingerprints.
Can a website use React for only one section?
Yes. React can be mounted into individual parts of an otherwise non-React website, such as search, comments, a cart or an interactive dashboard.
Final Thoughts
React is not always visible from one obvious fingerprint.
A client rendered application may expose clear JavaScript runtime clues, while a server rendered or Next.js application can arrive as complete HTML and hide much of its React implementation behind framework tooling.
The safest approach is to combine JavaScript analysis, React DevTools, DOM investigation and framework specific evidence.
Most importantly, confirm that the React code belongs to the main website rather than a third party widget before reporting the entire site as React powered.
For a faster first step, scan the website with WebBuildFinder and then manually verify the result.