How to Check What JavaScript Libraries a Website Uses

Want to know which JavaScript libraries power a website — jQuery, React, lodash, GSAP, Alpine, or some combination? You can usually find out in well under a minute using only the browser's built-in developer tools. The fastest method is to open the DevTools Console and test for each library's global object; a defined value means it is loaded. There are reliable backups too: reading script filenames in the Network tab, using detection extensions, and recognising runtime fingerprints. This guide covers all of them, including why bundlers sometimes hide the names and what to do about it.

For the front-end frameworks specifically — React, Vue and Angular — see the companion guide, how to check if a website uses React, Vue or Angular. Here we focus on libraries of every kind.

Why identify a site's JavaScript libraries?

The libraries a site loads tell you a lot about how it was built and maintained. Developers study how a competitor implemented an animation, a date picker or a data grid, and which tools they reached for. Performance engineers want to know whether a site is shipping heavy or redundant libraries — three different date libraries, say, or a full jQuery build used for one selector. Security reviewers check whether a site runs an old, vulnerable version of a popular library. And job seekers and recruiters verify the real client-side stack a company ships. Because most libraries expose themselves at runtime, all of this is observable from the outside without any special access.

The fastest check: console globals

The quickest and most decisive method is the Console. Open DevTools (F12 or right-click then Inspect), click the Console tab, and type the name of a library's global object. If it returns a function or object, the library is loaded; if it returns undefined, it is not. The most useful tests:

• jQuery — type window.jQuery or just $. To get the exact version, type jQuery.fn.jquery.
• React — window.React is sometimes defined, but more reliably check for __REACT_DEVTOOLS_GLOBAL_HOOK__.
• Vue — window.Vue for older versions, window.__VUE__ for Vue 3.
• lodash / Underscore — _ is the conventional global; _.VERSION prints the version.
• GSAP — window.gsap (or the older TweenMax).
• Moment.js — window.moment; moment.version prints the version.
• D3 — window.d3; d3.version prints the version.
• Alpine.js — window.Alpine.
• Axios — window.axios.

This works because a global is precisely how these libraries are meant to be used; if the page calls them, they are usually reachable from window.

A table of libraries and their console tells

Keep this handy as a quick reference for what to type and what confirms each library:

Library	Console test	Version check
jQuery	window.jQuery / $	jQuery.fn.jquery
lodash	_	_.VERSION
Underscore	_	_.VERSION
GSAP	window.gsap	gsap.version
Moment.js	window.moment	moment.version
Day.js	window.dayjs	—
D3.js	window.d3	d3.version
Three.js	window.THREE	THREE.REVISION
Alpine.js	window.Alpine	Alpine.version
Axios	window.axios	—
Swiper	window.Swiper	—
Chart.js	window.Chart	Chart.version

When a library has a version property, reading it is a bonus — it tells you not just that the library is present but whether it is current or dangerously old.

Reading the Network tab

The files a page downloads are the second great source of evidence, and often the easiest to scan. Open DevTools, go to the Network tab, reload the page, and click the JS filter to show only scripts. Then read the filenames and domains:

• Library files frequently keep recognisable names — jquery.min.js, lodash.min.js, gsap.min.js, swiper-bundle.min.js.
• CDN domains are a giveaway even when filenames are vague: code.jquery.com, cdnjs.cloudflare.com, cdn.jsdelivr.net and unpkg.com all serve named library files whose URLs include the library and version, for example .../ajax/libs/jquery/3.7.1/jquery.min.js.
• The Initiator column shows what requested each script, which helps you separate first-party code from third-party widgets.

The Network tab is especially good for libraries loaded straight from a public CDN, because the full versioned path is right there in the URL.

jQuery is still everywhere

It is tempting to assume the web has moved entirely to modern frameworks, but the data says otherwise. The HTTP Archive Web Almanac, which crawls millions of sites each year, consistently finds jQuery on the large majority of pages — it remains by a wide margin the most-used JavaScript library on the web, partly because WordPress and countless themes and plugins still bundle it. So when you start a detection, testing window.jQuery first is a high-yield move: more often than not it will be defined. Its ubiquity is also why a jQuery.fn.jquery version check is worth running — an ancient jQuery build is a common finding and a useful one, whether your interest is performance, compatibility or security.

Detection extensions and tools

If you would rather not test globals one by one, several tools automate the whole search:

• Wappalyzer — a browser extension and website that lists detected libraries, frameworks, analytics and more for the current page.
• BuiltWith — profiles a domain's full technology stack, including JavaScript libraries, with historical data on paid tiers.
• Library Detector (for Chrome/Firefox) — an extension built specifically to spot client-side JavaScript libraries on the page you are viewing, recognising dozens at once.
• View Source and DevTools — the manual tools that underpin everything above and let you verify any automated claim.
• StackOptic — a full website audit that reports the detected technologies alongside performance, SEO and security in a single pass.

These tools read the same globals and filenames you would; they just check many candidates instantly. When the answer matters, confirm a tool's result with a quick console test.

The big caveat: bundling and minification

The main reason library detection sometimes fails is the modern build pipeline. Tools like Webpack, Vite, Rollup and esbuild combine dozens of libraries into one or a few minified bundles with hashed names such as main.8f2c1a.js. The libraries are still inside, but their individual filenames vanish from the Network tab, and minification can rename or remove their global variables too. When this happens:

1. Lean on the Console. Many libraries are still attached to window even inside a bundle, so the global tests above often work regardless of how the code was built.
2. Look for source maps. A .map file referenced at the foot of a bundle can reveal the original module names — including library folders like node_modules/lodash — which is a goldmine for a deep review.
3. Use a detection extension that inspects the live runtime with heuristics rather than relying on filenames.

In short, when the network goes quiet, the runtime usually still talks. This is the same lesson that applies across the stack — see how to find out what a website is built with for the broader version.

Why too many libraries is its own signal

Detecting the libraries is often the start of a performance conversation, because the quantity and overlap of libraries is a finding in itself. It is common to discover a site shipping multiple tools that do the same job — Moment.js and Day.js together, or lodash loaded in full to use two functions — alongside a heavy jQuery build kept only for legacy reasons. Each library is bytes to download, parse and execute, and the cumulative weight is a leading cause of slow pages. So a library audit naturally feeds into a performance audit: once you can see everything a page loads, you can ask which libraries are still earning their place. That overlap between detection and optimisation is exactly why this check matters beyond curiosity, and it connects directly to how to reduce JavaScript and speed up your site.

Library, framework or language?

It is worth being clear about what you are detecting. A library is a focused toolkit your code calls on demand — jQuery, lodash, GSAP. A framework like React, Vue or Angular structures your whole app and calls your code; those have their own, usually stronger, fingerprints covered in how to check if a website uses React, Vue or Angular. And the server-side language that generates the page in the first place — PHP, Node.js, Python, Ruby — is a separate question entirely, answered through headers and cookies rather than client-side globals; see how to find out what programming language a website is built in. Knowing which layer you are looking at keeps your detection focused and your conclusions accurate.

Common mistakes

A few traps recur. Concluding "no library" from a quiet Network tab — bundling hides filenames, so always confirm with console globals before deciding a site ships no libraries. Mistaking a third-party widget's library for the site's own — an embedded chat or analytics widget may load its own copy of a library that the host site does not otherwise use. Ignoring versions — knowing a site uses jQuery is far less useful than knowing it uses an outdated, unsupported jQuery, so read the version property when one exists. And over-trusting a single tool — detectors are convenient but fallible, and a quick manual check is what turns a guess into a fact.

The fast, reliable workflow

1. Open the Console and test the most likely globals first ($/window.jQuery, then others).
2. Read versions where a property exists (jQuery.fn.jquery, _.VERSION).
3. Filter the Network tab by JS and scan filenames and CDN URLs.
4. Run a detection extension (Wappalyzer, Library Detector) and verify its list.
5. If bundled, look for source maps and rely on runtime globals.
6. Cross-check two signals before concluding, and note the versions, not just the names.

Go deeper

• The framework layer: how to check if a website uses React, Vue or Angular.
• The full method: how to find out what a website is built with.
• The server side: how to find out what programming language a website is built in.
• Turn the audit into action: how to reduce JavaScript and speed up your site.

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