core-js

What Is core-js?

core-js is the most widely bundled JavaScript polyfill library, providing standard-library shims that let modern JavaScript features run reliably in older browsers and environments. The short answer to what core-js is: it is a modular implementation of polyfills for ECMAScript features (and some web platform APIs), and rather than being added as a visible script tag, it is usually injected automatically into application bundles by build tools such as Babel. That is why core-js is detected on an enormous number of websites even though most site owners never deliberately install it by name.

core-js is maintained by Denis Pushkarev (known online as zloirock) and is one of the foundational pieces of the modern JavaScript build pipeline. It implements polyfills for features such as Promise, Symbol, Map, Set, WeakMap, iterators, Array methods like Array.from and Array.prototype.includes, Object methods, String methods, and many proposals at various stages of the standardization process. Precise market-share figures are difficult to state with confidence because core-js is almost always a transitive, bundled dependency rather than a standalone tag, and detection methodologies differ; treat any single percentage cautiously. What is consistently observed is that core-js is among the most depended-upon packages in the entire npm ecosystem, which means its polyfills end up inside a very large share of production JavaScript bundles served across the web.

Because it is typically injected by tooling, core-js is best understood not as a library developers call directly but as the invisible compatibility layer that makes "write modern, run everywhere" possible.

How core-js Works

core-js provides implementations of JavaScript standard-library features that may be missing in a given runtime. When code runs in an environment that already supports a feature natively, the native version is used; when it does not, core-js supplies a compliant replacement so the code behaves consistently.

There are two broad ways core-js delivers these polyfills, and the distinction matters for both detection and behavior.

Global polyfills patch the runtime by adding or modifying global objects and prototypes. Importing core-js this way makes features like Promise, Array.prototype.includes, or Object.assign available everywhere in the application. This is the simplest approach but it modifies global state, which can be undesirable for libraries shared with other code.

Pure (non-polluting) polyfills, available through core-js-pure, expose the same functionality without touching global objects, so a library can use modern features internally without affecting the host page. Build tools often use this mode when transforming library code.

In practice, most applications never import core-js manually. Instead, Babel does it for them. When configured with @babel/preset-env and a useBuiltIns setting of usage or entry, Babel analyzes the code and the project's browser targets (the browserslist configuration) and automatically injects exactly the core-js imports needed. With useBuiltIns: 'usage', Babel adds a polyfill only for each feature the code actually uses; with 'entry', it expands a single top-of-bundle import into the full set required by the targets. The result is that core-js modules appear inside the compiled bundle without ever being written by hand.

A defining detail is the __core-js_shared__ shared-state object. core-js stores internal metadata (such as registries used by its Symbol and well-known-symbol polyfills) on a shared object so that multiple copies or versions of core-js in the same realm can coordinate. The presence of this object on the global scope is one of the clearest runtime fingerprints that core-js is active.

Because the polyfills are split into hundreds of tiny modules, build tools can include only what a target environment lacks, keeping bundles as small as the compatibility requirements allow.

How to Tell if a Website Uses core-js

core-js is trickier to detect than a typical library because it rarely appears as a standalone script tag. The signals tend to live inside bundles and on the global object.

Signals in the page and network

• The __core-js_shared__ global. In the DevTools Console, type __core-js_shared__ or window['__core-js_shared__']. If an object is returned, core-js is active on the page. This is the single most reliable runtime signal.
• Version metadata. The shared object often contains version information; you can also check for core-js version markers embedded in bundle comments.
• Markers inside bundles. Use View Source or open JavaScript files in the Network tab and search for strings such as core-js, __core-js_shared__, or path fragments like node_modules/core-js/modules/. Build tools frequently preserve these module paths or banner comments.
• Polyfill chunk filenames. Some build setups emit a dedicated polyfills chunk (for example polyfills.<hash>.js in Angular projects or a vendor chunk) where core-js modules are concentrated.
• Babel signatures nearby. Because core-js is usually injected by Babel, you will often see Babel runtime helpers (such as _classCallCheck, _createClass, or regeneratorRuntime) in the same bundles.
• Rarely a CDN tag. Occasionally a site loads core-js directly from a CDN path like cdnjs.cloudflare.com/ajax/libs/core-js/ or unpkg.com/core-js-bundle, but this is the exception rather than the rule.

Tools to confirm it

Tool	What you do	What it reveals
DevTools Console	Type __core-js_shared__	Returns an object if core-js is active; the strongest runtime signal
View Source	Open bundles and search for core-js	Module paths and banner comments left by the build tool
DevTools Network	Open JS chunks and search within them	node_modules/core-js/modules/ paths and polyfill code
DevTools Network	Look for a polyfills chunk	A dedicated file where core-js shims are bundled
Wappalyzer	Run the browser extension on the page	May flag core-js in the JavaScript libraries / miscellaneous category
BuiltWith	Enter the domain on the BuiltWith site	Reports core-js detection where its signatures are present

For a broader walkthrough of identifying bundled dependencies and front-end libraries, see our guide on how to check what JavaScript libraries a website uses and the general primer on how to find out what technology a website uses.

Key Features

core-js is defined by breadth, modularity, and standards fidelity.

• Comprehensive ECMAScript polyfills. Implementations of Promise, Symbol, Map, Set, WeakMap, WeakSet, iterators, generators support, and many Array, Object, String, and Number methods.
• Proposal polyfills. Shims for ECMAScript proposals at various stages, letting teams adopt upcoming features early.
• Some web platform APIs. Polyfills for selected platform features such as URL, URLSearchParams, setImmediate, and queueMicrotask-style helpers.
• Highly modular. Hundreds of independent modules so tools can include only the polyfills a target environment lacks.
• Global and pure modes. A global-patching build and a non-polluting core-js-pure build for libraries.
• Babel integration. First-class support through @babel/preset-env with automatic, usage-based injection.
• Browserslist-aware. Works with target configurations so polyfills track the browsers a project actually supports.
• Shared-state coordination. The __core-js_shared__ object lets multiple instances cooperate within a realm.

Two features are especially important to how core-js behaves in production. First, its usage-based injection through Babel means the polyfill payload scales with both the features a codebase uses and the browsers it targets, so trimming the browserslist directly shrinks the bundle. Second, its modular structure is what allows that fine-grained inclusion in the first place; because each polyfill is its own module, a tool can pull in exactly core-js/modules/es.array.includes without dragging in the entire library.

Pros and Cons

core-js trade-offs are mostly about the cost of compatibility.

Pros

• Enables modern JavaScript to run reliably in older browsers and environments.
• Extremely comprehensive coverage of standard-library features and proposals.
• Highly modular, so only the needed polyfills are bundled.
• Standards-compliant implementations with strong attention to spec correctness.
• Integrates seamlessly with Babel, requiring little or no manual configuration.

Cons

• Adds bytes to bundles; over-broad browser targets can inflate payload significantly.
• Largely invisible to developers, which can make debugging and auditing harder.
• Global-patching mode modifies built-in prototypes, which some teams prefer to avoid.
• Version mismatches between multiple bundled copies can cause subtle issues.
• As legacy-browser support shrinks, the value of broad polyfilling decreases, and unnecessary polyfills become pure overhead.

core-js vs Alternatives

core-js competes with other polyfill strategies, though it is the dominant choice when build-tool integration matters. The table frames the options.

Option	Delivery	Coverage	Tooling integration	Notes
core-js	Bundled via Babel	Very broad (ES + proposals)	Excellent (preset-env)	The de facto standard polyfill set
Polyfill.io	Runtime CDN service	Broad, UA-targeted	Independent of build	Serves only what the requesting browser needs
Hand-picked polyfills	Manual imports	Narrow, chosen by you	Manual	Minimal size, maximal effort
No polyfills (modern targets)	None	N/A	N/A	Smallest output; drops legacy support

The most instructive comparison is core-js versus a runtime service like Polyfill.io. core-js bundles polyfills into your own JavaScript at build time, which gives you full control, no extra network dependency, and predictable behavior, at the cost of a larger bundle. Polyfill.io instead serves a tailored polyfill payload from a CDN based on the requesting browser's User-Agent, so each visitor downloads only what their browser actually lacks; the trade-off is reliance on a third-party endpoint and the variability that comes with it. For most modern build pipelines, core-js wins on control and reliability, which is why it has become the default. The broader trend, however, is that as support for very old browsers fades, many teams narrow their browserslist targets aggressively or drop polyfilling for the smallest, fastest bundles.

If you are auditing a build, core-js usually travels with a Babel toolchain and a bundler; recognizing it alongside other build artifacts helps you understand how a site is compiled.

Use Cases

core-js appears wherever modern JavaScript must run in less-than-modern environments.

• Broad browser support. Applications that must work in older browsers while letting developers write current-syntax JavaScript.
• Babel-compiled projects. Effectively any codebase using @babel/preset-env with usage- or entry-based polyfilling, which injects core-js automatically.
• Framework build output. Default Angular, and many React, Vue, and other bundler-based setups include core-js in their compiled output.
• Library distribution. Libraries using core-js-pure to rely on modern features internally without patching the host application's globals.
• Proposal adoption. Teams that want to use upcoming ECMAScript features before they are universally implemented.

For competitive research and lead generation, detecting core-js confirms that a site uses a modern build pipeline (typically Babel plus a bundler), which is a useful signal about the sophistication of a prospect's front-end engineering.

Frequently Asked Questions

Did I install core-js, or did a build tool add it?

In the vast majority of cases, a build tool added it for you. When you configure Babel with @babel/preset-env and useBuiltIns, Babel automatically injects core-js polyfills based on your code and your browser targets. Many framework starter kits (Angular notably) include it by default. That is why core-js shows up in bundles even when no one on the team wrote import 'core-js' by hand.

How do I detect core-js on a live website?

The most reliable method is to open your browser's DevTools Console and type __core-js_shared__. If it returns an object, core-js is active on the page. You can also open JavaScript bundles in View Source or the Network tab and search for strings like core-js or path fragments such as node_modules/core-js/modules/. Some projects emit a dedicated polyfills chunk where the shims are concentrated.

Does core-js slow down my website?

It adds bytes, and an overly broad set of browser targets can inflate your bundle with polyfills that most visitors never need. The impact is usually modest when core-js is configured with usage-based injection and a sensible browserslist, because only the necessary shims are included. The biggest wins come from narrowing your supported-browser list so the build tool ships fewer polyfills.

What is the difference between core-js and core-js-pure?

core-js (the standard build) patches global objects and prototypes, making polyfilled features available everywhere in the application. core-js-pure provides the same functionality without modifying any globals, exposing the implementations as importable values instead. Libraries prefer the pure build so they can use modern features internally without changing the behavior of the host page they are loaded into.

Is core-js still necessary if I only support modern browsers?

Less so. If your browserslist targets only recent browser versions, most ECMAScript features are natively supported and the polyfills become unnecessary overhead. Many teams now narrow their targets aggressively or drop polyfilling to ship smaller, faster bundles. core-js remains essential mainly when you must support older browsers or environments that lack newer standard-library features.

Want to identify the build tools, libraries, and full technology stack behind any website instantly? Try StackOptic at https://stackoptic.com.