jQuery in 2026: versions, support and where it runs

W3Techs finds jQuery on 64.5 % of all websites, and 78.8 % of those sites run a version 3 release; version 4 does not even appear in its list of versions. So when you take over a site that uses jQuery, the first questions are practical ones: which copy does the page run, does anyone still fix it, where did it come from, and should you keep it, upgrade it or remove it?

This lesson answers each question with the jQuery project’s own release and support facts, a short script that reports what any page runs, the versions that WordPress, Drupal, Magento and the ASP.NET Core template ship, and a table that weighs the three paths for your own site.

jQuery 4.0.0 is current, and 3.x gets only critical fixes

The jQuery team released jQuery 4.0.0 in 2026, the first major version in almost ten years: 3.0 came out in 2016. According to the release post, it removes APIs that had been deprecated for years, drops Internet Explorer 10 and older, and makes the slim buildslim build: A smaller build of jQuery without its Ajax and effects modules; in jQuery 4 it also leaves out Deferreds, Callbacks and queues. Its version string is 4.0.0+slim. More in “Loading jQuery: CDN, SRI, npm, slim and noConflict” smaller. Two companion projects followed within two weeks: jQuery MigratejQuery Migrate: A plugin from the jQuery team, loaded right after jQuery, that brings back APIs a newer jQuery removed or changed and, in its development build, logs a warning each time code uses one, so the code can be fixed before the upgrade. 4.0.2, the plugin that reports and restores what changed between 3.x and 4.x, and jQuery UI 1.14.2, whose team says the library is “in a maintenance state” and tested it with five jQuery releases, from 1.12.4 to 4.0.0. Walk through the releases behind the code you will meet:

Each major line is a branch. The jQuery repository rates the support each one gets today, and the support page says what critical-only means: 3.x “will only receive critical security patches and bug fixes”.

A site on 3.7.1 is not abandoned, but it will get critical fixes and nothing more. A site on 1.x or 2.x gets nothing at all, and the same support page points the owners of such sites to commercial support providers.

The npm registry draws a line of its own. 50 of the 64 releases of the jquery package carry a deprecation message: exactly the releases older than 3.5.0. That release fixed CVECVE: Common Vulnerabilities and Exposures: the public list that gives each known security flaw an identifier such as CVE-2020-11023, so that advisories, scanners and fixes all refer to the same problem.-2020-11023, a flaw that let HTML containing <option> elements run code when it was passed to .html(), .append() and similar methods, even after sanitising, in every release from 1.0.3 to 3.4.1 (NVD). In 2025 the US Cybersecurity and Infrastructure Security Agency added it to its catalogue of vulnerabilities known to be exploited.

One more trap: the API documentation runs ahead of the releases. api.jquery.com already describes an addition “as of jQuery 4.1”, the responseURL of a request object, and lists 3.8 among its versions, though neither release exists. Check the version a feature needs against the version your page runs before you use it.

Most jQuery sites run version 3 or older, and so does the advice you find

jQuery is still everywhere. W3Techs finds it on 85.6 % of the websites whose JavaScript library it can identify, which is 64.5 % of all websites, and the Stack Overflow developer survey of 2025 puts it third among web technologies, used by 23.4 % of the developers who answered, after Node.js (48.7 %) and React (44.7 %). For a maintainer, the list of versions matters more than the totals:

About one jQuery site in five runs a branch that nobody fixes, and almost all the others run 3.x. Version 4 is too new to register yet.

The help you find online is just as old. Stack Overflow holds over a million questions tagged jquery. In 2021 people asked 21,672 new ones, about 1,800 a month; since jQuery 4.0.0 came out, only a few dozen have been asked in all, by the counts of the Stack Exchange API. Almost every answer, tutorial and snippet you will find was written for 1.x to 3.x, so it may call an API that jQuery 4 removed, such as $.trim() or $.isArray(), which the 4.0 upgrade guide replaces with the string’s own .trim() and Array.isArray().

Ask the page which jQuery it runs

Before you plan anything, check what the page loads. Every jQuery object carries the version string in jQuery.fn.jquery (API documentation), and three more checks tell you the rest: what follows the version number names the build, jQuery Migrate sets jQuery.migrateVersion (Migrate README), and comparing window.$ with window.jQuery says whether $ is jQuery at all. This script reads all of them; paste it into the browser console of the page you are checking:

// report.js: which jQuery does this page run? Paste it into the browser console of any page.
(function (win) {
  const jq = win.jQuery;
  if (!jq || !jq.fn || !jq.fn.jquery) {
    console.log('No jQuery on this page: window.jQuery is not set');
    return;
  }
  // "3.7.1" or "4.0.0" for a full build, "4.0.0+slim", or "3.7.1 -ajax,…" with the modules left out.
  const full = jq.fn.jquery;
  const number = full.split(/[ +]/)[0];
  const slim = full.includes('+slim') || (full.includes('-ajax') && full.includes('-effects'));
  const build = full === number ? 'full build' : slim ? 'slim build' : 'custom build';
  console.log(`jQuery ${number}, ${build}`);
  console.log(`jQuery Migrate: ${jq.migrateVersion || 'not loaded'}`);
  console.log(`window.$: ${win.$ === jq ? 'this jQuery' : win.$ ? 'another library' : 'not set'}`);
  // The plugins your own code calls, by the name it calls them with.
  for (const name of ['cartBadge', 'datepicker']) {
    console.log(`.${name}(): ${typeof jq.fn[name] === 'function' ? 'loaded' : 'missing'}`);
  }
})(window);

It ran on three pages in jsdom, a DOM implementation for Node.js, with the official files of code.jquery.com: a shop theme on jQuery 3.7.1 with Migrate 3.4.1, loaded the way WordPress 7.1 loads them; the same shop upgraded to 4.0.0 with the development build of Migrate 4.0.2; and a landing page on the slim build of 4.0.0:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Bakery shop: a theme on jQuery 3.7.1</title>
  </head>
  <body>
    <p id="cart">Cart</p>
    <!-- As WordPress 7.1 loads them: jQuery 3.7.1, which its copy follows with noConflict(), then Migrate 3.4.1. -->
    <script src="https://code.jquery.com/jquery-3.7.1.min.js" integrity="sha256-/JqT3SQfawRcv/BIHPThkBvs0OEvtFFmqPF/lYI/Cxo=" crossorigin="anonymous"></script>
    <script>jQuery.noConflict();</script>
    <script src="https://code.jquery.com/jquery-migrate-3.4.1.min.js" integrity="sha256-UnTxHm+zKuDPLfufgEMnKGXDl6fEIjtM+n1Q6lL73ok=" crossorigin="anonymous"></script>
    <script src="../cart-badge.js"></script>
    <script src="../report.js"></script>
  </body>
</html>

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Bakery shop: upgraded to jQuery 4.0.0</title>
  </head>
  <body>
    <p id="cart">Cart</p>
    <!-- During an upgrade: jQuery 4.0.0 with the development build of Migrate 4.0.2, which logs what it finds. -->
    <script src="https://code.jquery.com/jquery-4.0.0.min.js" integrity="sha256-OaVG6prZf4v69dPg6PhVattBXkcOWQB62pdZ3ORyrao=" crossorigin="anonymous"></script>
    <script src="https://code.jquery.com/jquery-migrate-4.0.2.js" integrity="sha256-4jeVh9jfwyyopEc4//vH8BKuFP0q9ElJZLsJrTEcZjI=" crossorigin="anonymous"></script>
    <script src="../cart-badge.js"></script>
    <script src="../report.js"></script>
  </body>
</html>

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Landing page: the slim build of jQuery 4.0.0</title>
  </head>
  <body>
    <p id="cart">Cart</p>
    <script src="https://code.jquery.com/jquery-4.0.0.slim.min.js" integrity="sha256-8DGpv13HIm+5iDNWw1XqxgFB4mj+yOKFNb+tHBZOowc=" crossorigin="anonymous"></script>
    <script src="../report.js"></script>
  </body>
</html>

// cart-badge.js: a small plugin. It adds .cartBadge() to the copy of jQuery that is loaded when it runs.
(function ($) {
  $.fn.cartBadge = function (count) {
    return this.each(function () {
      $(this).attr('data-count', String(count));
    });
  };
})(jQuery);

// Prints what report.js logged on three pages in jsdom (recorded.mjs), page by page.
import { show } from './show.mjs';

for (const page of ['pages/theme.html', 'pages/upgraded.html', 'pages/slim.html']) {
  console.log(`${page}:`);
  show(page);
}

pages/theme.html:
JQMIGRATE: Migrate is installed, version 3.4.1
jQuery 3.7.1, full build
jQuery Migrate: 3.4.1
window.$: not set
.cartBadge(): loaded
.datepicker(): missing
pages/upgraded.html:
JQMIGRATE: Migrate is installed with logging active, version 4.0.2
jQuery 4.0.0, full build
jQuery Migrate: 4.0.2
window.$: this jQuery
.cartBadge(): loaded
.datepicker(): missing
pages/slim.html:
jQuery 4.0.0, slim build
jQuery Migrate: not loaded
window.$: this jQuery
.cartBadge(): missing
.datepicker(): missing

Read the output page by page:

• The theme page says window.$: not set. Its copy of jQuery handed $ back with jQuery.noConflict(), as the copy that WordPress builds does at its end (Gruntfile.js), so code on that page must write jQuery(…) or receive $ as a parameter, the subject of this module’s third lesson.
• Migrate speaks first. Its production build of 3.4.1 says that it is installed; the development build of 4.0.2 says that its logging is on, so its warnings appear in the console while you test.
• The slim page reports slim build because its version string is 4.0.0+slim. On 3.x, a slim build’s string lists the modules it leaves out instead.
• .cartBadge() is missing on the slim page because that page never loads the plugin. When the console says that a plugin method “is not a function”, the plugin was not loaded, was loaded before jQuery, or belongs to another copy of jQuery on the same page.

A site’s jQuery comes with its platform, theme or template

Few sites choose their jQuery release on purpose: it arrives with the platform, the theme or the project template, and each of them pins its own. These are the copies the main platforms ship, read from their source code:

Bootstrap is the odd one out: the introduction of version 4.6 says that many of its components “require jQuery”, while Bootstrap 5 dropped that dependency (migration guide). So a framework can be the only reason a page loads jQuery.

The other copies come from themes and plugins that bring their own jQuery, and from old templates that load it from a CDNCDN: A content delivery network: servers in many places that keep copies of files such as jquery-4.0.0.min.js and send each visitor the copy from a server near them. More in “Loading jQuery: CDN, SRI, npm, slim and noConflict”. Google Hosted Libraries offers no jQuery 4: its newest jQuery is 3.7.1, so a page that loads ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js cannot be upgraded by editing the number in the address. When a report shows a version that the platform does not ship, such as 3.6.0 on WordPress 7.1, look for the theme or plugin that loaded a copy of its own.

Maintain, upgrade or remove: one decision per site

Every site that runs jQuery is on one of three paths, and the version it runs today narrows the choice:

• Maintain: keep the release and fix bugs carefully. This is a fair choice on a supported branch, 4.x or 3.x, when an upgrade would cost more than the site’s remaining life is worth. On 1.x and 2.x it means living with CVE-2020-11023 and with no fixes at all.
• Upgrade: move to jQuery 4 with jQuery Migrate. The Migrate README pairs Migrate 3 with jQuery 3.x and Migrate 4 with 4.x, and says that the way to 4.x goes through 3.x, so a site on 1.x or 2.x takes at least two steps.
• Remove: replace jQuery with the browser’s own DOM APIs, one part of the code at a time, the subject of this track’s migration module. It pays off on code that keeps changing, and only for the jQuery your own code loads.

A platform changes the picture: WordPress.org’s plugin rules say that plugins “must use the versions of those libraries packaged with WordPress”, so a plugin works with the platform’s jQuery instead of loading a copy of its own. Answer four questions about a site you look after, and the table marks the paths that fit it:

In short: a site on 1.x or 2.x upgrades through 3.x, a site on 3.x maintains for a while and plans for 4.x, code for a platform follows the platform’s version, and removal suits code you own that keeps changing.

Practise: report and decide

Write the report as a function that the rest of your tools can call, and check it against the version strings the real builds report. The sample tests run in your browser:

/**
 * What a page's window says about its jQuery: the version, the build, jQuery Migrate and who owns $.
 * @param {object} win the page's window (window in a browser)
 * @returns {{ version: string, build: 'full' | 'slim' | 'custom', migrate: string | null, dollar: 'jquery' | 'other' | 'none' } | null}
 */
export function getJQueryReport(win) {
  return null;
}

import { test, assert } from 'mysmartcopilot:test';
import { getJQueryReport } from './report.mjs';

// Plain objects shaped like the parts of window that the function reads, with the version strings the real builds
// report (jQuery.fn.jquery) and the values jQuery Migrate sets (jQuery.migrateVersion).
function page(versionString, { migrate, dollar = 'jquery' } = {}) {
  const jQuery = { fn: { jquery: versionString } };
  if (migrate) jQuery.migrateVersion = migrate;
  const win = { jQuery };
  if (dollar === 'jquery') win.$ = jQuery;
  else if (dollar === 'other') win.$ = function otherLibrary(id) { return id; };
  return win;
}
const SLIM_371 = '3.7.1 -ajax,-ajax/jsonp,-ajax/load,-ajax/script,-ajax/var/location,-ajax/var/nonce,-ajax/var/rquery,-ajax/xhr,-manipulation/_evalUrl,-deprecated/ajax-event-alias,-effects,-effects/animatedSelector,-effects/Tween';

test('a theme on 3.7.1 with Migrate 3.4.1, after noConflict()', () => {
  assert.deepEqual(getJQueryReport(page('3.7.1', { migrate: '3.4.1', dollar: 'none' })), { version: '3.7.1', build: 'full', migrate: '3.4.1', dollar: 'none' });
});

test('an upgraded page on 4.0.0 with Migrate 4.0.2', () => {
  assert.deepEqual(getJQueryReport(page('4.0.0', { migrate: '4.0.2' })), { version: '4.0.0', build: 'full', migrate: '4.0.2', dollar: 'jquery' });
});

test("the slim build of 4.0.0 reports '4.0.0+slim'", () => {
  assert.deepEqual(getJQueryReport(page('4.0.0+slim')), { version: '4.0.0', build: 'slim', migrate: null, dollar: 'jquery' });
});

test("the slim build of 3.7.1 lists the modules it leaves out", () => {
  assert.deepEqual(getJQueryReport(page(SLIM_371)), { version: '3.7.1', build: 'slim', migrate: null, dollar: 'jquery' });
});

test('a build that leaves out other modules is custom', () => {
  assert.equal(getJQueryReport(page('3.7.1 -deprecated')).build, 'custom');
  assert.equal(getJQueryReport(page('3.7.1 -ajax')).build, 'custom', 'without -effects it is not the slim build');
  assert.equal(getJQueryReport(page('3.7.1 -effects,-effects/Tween')).build, 'custom', 'without -ajax it is not the slim build');
});

test('$ that belongs to another library', () => {
  assert.equal(getJQueryReport(page('4.0.0', { dollar: 'other' })).dollar, 'other');
});

test('a page without jQuery', () => {
  assert.equal(getJQueryReport({}), null);
  assert.equal(getJQueryReport({ jQuery: {} }), null, 'an object called jQuery without fn.jquery is not jQuery');
  assert.equal(getJQueryReport({ jQuery: { fn: {} } }), null);
});

Then answer the lesson’s own questions. They start with what you know least, and every answer says why it is right or what it misses:

Interview questions

Warm-up (fresher to 2–5 years): how do you tell which jQuery a page runs, and whether jQuery Migrate is loaded?

Open the browser console on the page and read jQuery.fn.jquery: it holds the version, such as 3.7.1, and anything after the number names the build, +slim on 4.x or a list of left-out modules on 3.x. jQuery.migrateVersion is set only when jQuery Migrate is loaded, and Migrate logs a line when it starts, which in its development build says that logging is active. Compare window.$ with window.jQuery to see whether $ is jQuery, another library or nothing, as on WordPress, whose copy calls jQuery.noConflict(). Ask the running page rather than reading file names, because a theme or plugin may load a second copy that replaces the first.

Two harder questions follow, about a shop on jQuery 1.12.4 and a plugin that ships its own jQuery. Decide what you would say before you open each first step:

Key takeaways

• jQuery 4.0.0 is the current release, with jQuery Migrate 4.0.2 and jQuery UI 1.14.2; 3.x gets critical fixes only, and 1.x and 2.x get none.
• npm marks every release older than 3.5.0 as deprecated, and those releases have CVE-2020-11023, which CISA lists as exploited.
• Most jQuery sites, and almost all the advice online, are on 1.x to 3.x, so check every API an old answer uses against the version you run.
• jQuery.fn.jquery, jQuery.migrateVersion and window.$ === window.jQuery tell you what a page really runs.
• A site’s copy usually comes from its platform, theme or template, and the version it runs today decides whether to maintain, to upgrade through 3.x, or to remove jQuery part by part.