jQuery 4.0.0 Official Release: A 20-Year Milestone for the Web

by jQueryScript, 01/19/2026 00:54:24 UTC

It has been exactly two decades since John Resig released the first version of jQuery at BarCamp NYC. The date was January 14, 2006. The web was a chaotic place. Browsers fought over standards. document.getElementById was verbose. We needed a hero. jQuery was that hero.

Now, in 2026, the landscape looks different. React, Vue, and Svelte dominate new development. Yet, jQuery remains the backbone of the internet. It powers millions of legacy sites, WordPress themes, and enterprise dashboards.

The jQuery team has officially released jQuery 4.0.0. This is the first major release in nearly ten years. It represents a shift from "compatibility at all costs" to "modernization where possible."

jQuery 4.0.0 Official Release

This release matters primarily for teams maintaining legacy codebases. If your application depends on jQuery for DOM manipulation, AJAX requests, or animation, you need to understand what broke and what stayed the same.

The changes are significant enough that the team released a companion migration guide and updated the jQuery Migrate plugin to help identify compatibility issues.

Browser Support: The Internet Explorer Funeral

jQuery 4.0 drops support for Internet Explorer 10 and all earlier versions. The team preserved IE11 support temporarily but plans to remove it in jQuery 5.0. This staged deprecation approach gives enterprise teams additional time to phase out legacy browser requirements.

The removed browser list also includes Edge Legacy (the pre-Chromium version), iOS versions older than the most recent three releases, Firefox versions older than the most recent two (excluding ESR), and Android Browser. The current support matrix covers IE11, Chrome/Edge/Firefox/Safari (current and previous versions), Opera (current), iOS Safari (current through current minus two), and Android (current and previous).

This browser purge allowed the team to delete substantial compatibility code. The removal of IE-specific workarounds alone accounts for a measurable portion of the file size reduction.

ES Module Migration: Build Tool Compatibility

The jQuery source code now uses ES modules instead of AMD. Developers who import jQuery's source directly via RequireJS will need to adjust their workflows. The primary jQuery distribution file remains a UMD module that works in both AMD and non-AMD environments.

The ES module architecture makes jQuery compatible with modern bundlers. Vite, Webpack 5, and Rollup can now process jQuery as a standard ES module dependency. The team also added an exports field to package.json that specifies which build gets loaded in different environments. This change supports better tree-shaking and improves integration with server-side rendering frameworks.

The migration to ES modules required the team to switch from RequireJS to Rollup as the build tool. All tests now run against the ES module source separately to catch module-specific issues.

Removed APIs: The Deprecation Backlog

jQuery 4.0 removes 13 utility methods that browsers now implement natively. The deleted functions include jQuery.isArray, jQuery.parseJSON, jQuery.trim, jQuery.type, jQuery.now, jQuery.isNumeric, jQuery.isFunction, jQuery.isWindow, jQuery.camelCase, jQuery.nodeName, jQuery.cssNumber, jQuery.cssProps, and jQuery.fx.interval.

Developers should replace these with native equivalents:

jQuery.isArray: Use Array.isArray() for type checking arrays.

jQuery.parseJSON: Use JSON.parse() for parsing JSON strings.

jQuery.trim: Use String.prototype.trim() to remove whitespace.

jQuery.now: Use Date.now() to get the current timestamp.

jQuery.type: Use typeof for primitives, Array.isArray for arrays, and instanceof for objects.

The team also removed three undocumented array methods from the jQuery prototype: push, sort, and splice. These methods copied the behavior of native Array methods but served no documented purpose. Plugin developers who relied on these methods will need to refactor. The replacement pattern looks like this: [].push.call($elems, elem) instead of $elems.push(elem).

Focus Event Order: Standards Compliance

Browsers disagreed about the firing order of focus, blur, focusin, and focusout events for years. Modern browsers finally converged on a standard order, but it differs from the order jQuery enforced in previous versions.

jQuery 4.0 stops overriding native behavior. The new order follows the W3C specification: blur, focusout, focus, focusin. Previous jQuery versions fired events in this order: focusout, blur, focusin, focus. Internet Explorer was the only browser that matched the original W3C spec before it changed in 2023.

This change affects code that depends on specific event timing. Developers who set up handlers expecting the old order may see unexpected behavior. The practical impact appears limited. Most event handlers operate independently rather than depending on execution sequence.

CSS Property Changes: Manual Units Required

jQuery no longer automatically appends "px" to unitless numeric values for most CSS properties. Previous versions added the unit automatically with certain exceptions. Version 4.0 inverts this logic. The library now adds "px" only to a small list of known properties that require it.

Developers who pass unitless numbers to .css() for properties like margin, padding, or width will need to add the unit explicitly:

Before: $elem.css("margin", 20) set margin to "20px"

After: $elem.css("margin", 20) sets margin to "20" (invalid in most contexts)

Correct: $elem.css("margin", "20px") sets margin to "20px"

The team also removed the opacity CSS hook. The .css("opacity") method now returns an empty string for detached elements in standards-compliant browsers and returns "1" in IE11. This aligns opacity with the behavior of other CSS properties but may break code that assumes opacity always returns a numeric value.

AJAX Module: Security Hardening

jQuery 4.0 removes the automatic promotion of JSON requests to JSONP. Previous versions converted any request with dataType: "json" and a callback parameter to JSONP automatically. This created a security vulnerability. Developers could unknowingly execute code from remote domains.

The new behavior requires explicit dataType: "jsonp" to trigger JSONP requests. JSON requests with callbacks now fail unless the backend supports CORS. All browsers jQuery 4.0 supports implement CORS correctly.

The team also stopped auto-executing scripts fetched via jQuery.ajax unless developers specify dataType: "script". This change previously applied only to cross-domain scripts in jQuery 3.0. Version 4.0 extends the requirement to same-domain scripts.

Script loading now uses script tags for all asynchronous requests instead of XHR. This avoids Content Security Policy violations. The previous implementation used script tags only for cross-domain requests or requests with the scriptAttrs option. The new approach may affect code that expects scripts to execute even when CSP headers block inline script execution.

Slim Build: Deferreds Removed

The slim build excludes the Deferred, Callback, and Queue modules. The minified gzipped size dropped to approximately 19.5KB. Native Promises replaced most Deferred use cases. All browsers except IE11 support Promise natively.

Developers who use Deferred-specific features that native Promises lack will need to stick with the full build or add a Promise polyfill for IE11 support. The team documented which Deferred features lack Promise equivalents in the migration guide.

Trusted Types: CSP Enhancement

jQuery 4.0 adds Trusted Types support for all manipulation methods. This allows HTML wrapped in TrustedHTML to pass through jQuery's DOM manipulation functions without violating the require-trusted-types-for Content Security Policy directive.

The implementation required changes to the buildFragment function. The team stopped concatenating strings during fragment creation. This change should not affect most codebases, but developers who relied on specific string concatenation behavior may see differences.

Migration Path: jQuery Migrate Plugin

The jQuery Migrate 4.0 plugin detects compatibility issues and provides console warnings. The uncompressed development version logs specific warnings when deprecated or removed features execute. The compressed version restores old behavior silently for production use.

Teams currently running jQuery 1.8 or older should first upgrade to jQuery 1.x or 2.x with the Migrate 1.x plugin before jumping to 4.0. Teams running jQuery 1.9 or newer can upgrade directly to 4.0 with the Migrate 3.6.0 plugin. The Migrate 4.x plugin will support the same browsers as jQuery 4.x but has not yet been released.

The migration workflow follows this pattern:

Update jQuery to version 4.0.0 on a development environment.
Addthe uncompressed jQuery Migrate plugin.
Load the site and check the browser console for warnings.
Fix each warning using the migration guide.
Test thoroughly with the Migrate plugin removed.
Deploy to production.

The team recommends upgrading plugins to their latest versions before starting migration. Newer plugin releases generally handle jQuery version changes better than older releases.

Download Options

The CDN hosts both the full and slim builds:

Full build: https://code.jquery.com/jquery-4.0.0.min.js

Slim build: https://code.jquery.com/jquery-4.0.0.slim.min.js

NPM users can install via: npm install [email protected]

Third-party CDNs need time to mirror the release. The official jQuery CDN provides immediate access.

Upgrade or Rewrite: Strategic Decision Framework

Teams maintaining legacy applications face a decision point. Upgrading to jQuery 4.0 delivers performance improvements and security enhancements with relatively low migration effort. The jQuery Migrate plugin catches most breaking changes automatically. Sites with moderate jQuery usage can likely upgrade in days rather than weeks.

The upgrade makes sense when your codebase still depends on jQuery for core functionality and you lack the budget for a complete rewrite. Version 4.0 will receive security updates and bug fixes for years. The browser support matrix aligns with modern browser usage patterns.

Rewriting makes sense when your jQuery code represents a small fraction of total application logic or when you plan a larger architectural overhaul. Modern frameworks handle state management, component composition, and reactive updates more elegantly than jQuery's imperative DOM manipulation model. React, Vue, and Svelte all provide better developer experiences for building complex interactive applications.

Teams choosing to rewrite should consider that jQuery 3.x remains viable. The team will maintain version 3 with security patches. There is no immediate pressure to migrate unless you need specific 4.0 features or encounter browser support conflicts.

The 20-Year Legacy

jQuery democratized JavaScript development at a time when browsers implemented features inconsistently. The library made AJAX accessible, normalized event handling, and provided a clean API for DOM manipulation. Millions of developers learned JavaScript through jQuery.

The web evolved past the problems jQuery originally solved. Modern browsers converge on standards. Native APIs now provide the functionality jQuery wrapped. Build tools optimize bundle sizes automatically. The ecosystem moved toward component-based architectures.

jQuery 4.0 acknowledges this evolution. The team trimmed legacy compatibility code and embraced modern JavaScript features. The library serves teams maintaining existing codebases rather than teams starting new projects. This focus makes sense. The installed base remains enormous. Production sites depend on jQuery. They need a stable, maintained library that works with current browsers.

Version 4.0 delivers exactly that. It respects jQuery's history while accepting its narrower role in the modern web development ecosystem.