What Is a Polyfill?
A polyfill is a piece of JavaScript that adds a modern browser feature to older browsers that lack it, so your code can use that feature everywhere. It detects whether the native capability exists and, if not, supplies a substitute written in code the older browser already understands. The name comes from a filler paste: a polyfill fills the gaps in browser support. Developers use polyfills to write with current standards while still serving visitors on outdated browsers, keeping a single codebase working across old and new.
- What it does
- Adds missing native features to older browsers using JavaScript
- Coined by
- Developer Remy Sharp in 2009, borrowing from the filler product Polyfilla
- Common examples
- fetch, Promise, Array methods, and IntersectionObserver
- Loaded conditionally
- Best practice serves polyfills only to browsers that need them (web.dev)
- Related to
- Transpiling, which converts syntax rather than adding features (MDN)
What a polyfill actually does #
A polyfill is code, almost always JavaScript, that implements a browser feature the browser does not have built in. Say a newer method exists in current browsers but an older one predates it. Rather than avoid the method or write two versions of your site, you include a polyfill that recreates the missing feature. Once loaded, your code calls the feature normally, and the polyfill quietly stands in where the native version is absent. This lets developers write against modern web standards while still supporting visitors whose browsers lag behind. Polyfills exist for a wide range of capabilities, from JavaScript methods to newer APIs like geolocation or intersection observers. They are a bridge between what standards define and what real browsers have actually shipped. For a business, they are invisible but valuable: they mean your site can use current techniques without abandoning customers on older devices. Our /services/web-app-development work uses polyfills selectively so modern features never lock out real users.
Where the term comes from #
The word polyfill was coined by British developer Remy Sharp in 2009. He borrowed it from Polyfilla, a UK brand of paste used to fill cracks and holes in walls before painting. The metaphor is apt: a polyfill fills the gaps in a browser's feature support so the surface you build on feels smooth and complete. Before the term caught on, developers called these workarounds shims or fallbacks, and those words are still used, though a shim more broadly means any compatibility layer. The concept predates the name; developers have patched missing browser features since the early days of the web. What Sharp captured was the specific idea of replicating a standard feature so faithfully that your own code cannot tell whether the browser or the polyfill is providing it. That transparency is the goal. Understanding the vocabulary helps when reading documentation or talking to a developer; our /wiki library defines related terms like shim, transpiling, and feature detection in the same plain language.
How a polyfill works #
A well-written polyfill does not blindly overwrite anything. It first checks whether the browser already supports the feature, a practice called feature detection. If the native capability exists, the polyfill steps aside and lets the browser use its own faster, built-in version. Only when the feature is missing does the polyfill install its substitute. This check matters, because replacing a native feature with slower JavaScript on browsers that do not need it wastes performance. Feature detection typically tests whether a property or method exists on the relevant object before acting. Many polyfills are distributed as small standalone files or bundled through services that assemble only the polyfills a given browser requires. The substitute code is written using older, widely supported techniques, since it must run in the very browsers that lack the modern feature. Done properly, the result is seamless: your application calls the feature the same way everywhere. If your site behaves differently across browsers, our /tools/website-grader can help surface where compatibility is breaking down.
Polyfill versus transpiling #
Polyfills and transpiling are often confused because both help modern code run in older browsers, but they solve different problems. Transpiling converts new syntax into older equivalent syntax before the browser ever sees it, handled by tools like Babel during a build step (MDN). A polyfill, by contrast, adds a missing feature or API at runtime, in the browser itself. Put simply: transpiling rewrites how code is written, while a polyfill supplies functionality that is missing. New JavaScript syntax such as arrow functions is a transpiling job; a missing method or a newer browser API is a polyfill job. A typical modern project uses both together, transpiling syntax and polyfilling absent features, so the finished site runs correctly across a broad range of browsers. You rarely choose one over the other; they cover complementary gaps. Our /services/web-app-development and /wiki resources explain how these build-time and run-time tools fit into a professional workflow, so the finished product works reliably without bloating for users on current browsers.
Feature detection before polyfilling #
A safe polyfill checks for native support first and only defines the feature when it is genuinely missing.
// Only add the feature if the browser lacks it
if (!("fetch" in window)) {
// Load a fetch polyfill, or define a fallback
window.fetch = function (url, options) {
return new Promise(function (resolve, reject) {
var xhr = new XMLHttpRequest();
xhr.open((options && options.method) || "GET", url);
xhr.onload = function () {
resolve({ text: function () { return xhr.responseText; } });
};
xhr.onerror = reject;
xhr.send((options && options.body) || null);
});
};
}Do you still need polyfills in 2026? #
Less than you used to, but sometimes yes. Modern browsers update automatically and share a common baseline, so many features that once required polyfills are now natively supported everywhere. That has shrunk the everyday need for them. Still, polyfills remain relevant in specific cases: audiences that include older devices, corporate environments locked to outdated browsers, certain smart TVs and kiosks, and brand-new features that have not yet reached universal support. Whether you need one depends entirely on who visits your site, which is why analytics data matters. If almost no one uses a browser that lacks a feature, adding a polyfill just slows everyone else down for no benefit. If a meaningful slice of your customers is on older software, skipping the polyfill quietly breaks the site for them. The honest answer is: measure your actual audience before deciding. Our /services/analytics-tracking work helps you see which browsers your customers really use, so polyfill decisions rest on data rather than guesswork or fear.
The performance cost of polyfills #
Polyfills are not free. Every one you ship is extra JavaScript the browser must download, parse, and run, which adds weight and can slow the very devices that most need the help. The professional approach is to serve polyfills only to the browsers that lack the feature, not to everyone. Techniques for this include conditional loading based on feature detection and using services that inspect the visitor's browser and send a tailored bundle (web.dev). Bundling every possible polyfill into one file that every visitor downloads is a common mistake that hurts performance for the majority on modern browsers. Because speed affects both conversions and search rankings through Core Web Vitals, unnecessary polyfills carry a real business cost. The goal is balance: support the users who need it without penalizing those who do not. If your site feels sluggish, oversized scripts are a frequent culprit, and our /services/speed-optimization work regularly finds bloated or outdated polyfills among the causes worth trimming for a faster page.
What polyfills mean for your website #
You will probably never write a polyfill yourself, but the concept affects your site's reliability and cost. Polyfills let developers use current techniques while still supporting your full audience, which protects customers on older phones or restricted work computers from a broken experience. The tradeoff is added code, so a careful developer weighs whether a given polyfill is worth the weight for your specific visitors. The wrong extreme in either direction hurts you: too many polyfills slow the site, while ignoring browser support entirely can silently lose customers who never report the problem. This is one of many judgment calls that separate a professional build from a template thrown online. If your site works perfectly on your own machine but you have heard complaints from certain customers, browser compatibility handled through polyfills and fallbacks is a likely factor. A /free-website-audit can check how your site holds up across the range of browsers your customers actually use, not just the newest one on your desk.
The bottom line on polyfills #
A polyfill is a small piece of JavaScript that teaches an older browser a feature it is missing, letting developers write to modern standards without abandoning visitors on outdated software. It checks for native support first, then fills the gap only when needed. Polyfills differ from transpiling, which rewrites syntax rather than supplying features, and the two are usually used together. In 2026 the need has shrunk as browsers converged, but polyfills still matter for older devices, locked-down corporate machines, and cutting-edge features. The key is restraint: serve them only where required, because every polyfill adds weight that can slow performance. For a business, this is a developer's concern that quietly affects your reach and speed. If you want a site that works everywhere without unnecessary bloat, our /services/web-app-development page explains how we balance modern features against real-world browser support, and /contact reaches someone who can review your case directly.
FAQ
What does a polyfill do?
A polyfill adds a modern browser feature to older browsers that lack it. It checks whether the browser already supports the feature and, if not, supplies a substitute written in JavaScript the older browser understands. This lets developers use current web standards while still serving visitors on outdated browsers from a single codebase.
What is the difference between a polyfill and a shim?
The terms overlap. A shim is any compatibility layer that intercepts calls and provides expected behavior, sometimes changing an API. A polyfill is a specific kind of shim that replicates a standard browser feature faithfully, so your code cannot tell whether the browser or the polyfill provides it. Every polyfill is a shim, but not every shim is a polyfill.
Is a polyfill the same as transpiling?
No. Transpiling converts modern syntax into older equivalent syntax during a build step, using tools like Babel. A polyfill adds a missing feature or API at runtime in the browser. Syntax is a transpiling job; missing functionality is a polyfill job. Modern projects usually use both together to run reliably across old and new browsers.
Do I still need polyfills in 2026?
Often not, because modern browsers now share a common baseline and update automatically. But you may still need them for older devices, corporate machines locked to outdated browsers, kiosks, smart TVs, or brand-new features lacking universal support. The right choice depends on which browsers your actual visitors use, which is why analytics data matters.
Do polyfills slow down a website?
They can. Each polyfill is extra JavaScript to download and run, which adds weight and can slow performance. The fix is to serve polyfills only to browsers that need them, using feature detection or a service that sends a tailored bundle. Loading every polyfill for every visitor is a common mistake that hurts speed unnecessarily.
Where does the word polyfill come from?
Developer Remy Sharp coined it in 2009, borrowing from Polyfilla, a British brand of paste used to fill cracks in walls before painting. The metaphor fits: a polyfill fills gaps in a browser's feature support so your code has a smooth, complete surface to build on. Earlier developers called similar workarounds shims or fallbacks.
How Local Web Advisor checks this for you
Is your own website getting web dev right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web dev and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?