The jQuery UI latest version is in the 1.14.x line, first released in August 2024, and the project has formally entered maintenance mode: it stays compatible with new jQuery releases and fixes security issues, but no significant new feature work is planned. If you are checking the jQuery UI latest version because you inherited a codebase that still leans on it, the practical answer is to move to 1.14.x, understand the maintenance status, and plan a migration path rather than treating it as a living framework.
jQuery UI shaped a decade of web interfaces with its widgets, effects, and interactions. It is not dead, but it is done growing, and that distinction drives how you should manage it.
What "Latest Version" Actually Means Here
The 1.14.0 release landed in August 2024 and marked a deliberate pivot toward reducing maintenance burden rather than adding features. Subsequent 1.14.x patch releases followed to fix specific issues, including tab-widget behavior with unusual IDs. The older 1.13.x line is no longer supported, so anyone still on 1.13 or earlier should move up.
The headline is not the version number; it is the posture. jQuery UI is now a stability project. That is not automatically a problem: plenty of dependencies live long, useful lives in maintenance mode. It does mean you should not expect modern accessibility improvements, new widgets, or framework integrations to arrive.
The jQuery Migrate Angle
If you are auditing jQuery UI, you are almost always also on some version of jQuery core, and that is where jQuery Migrate comes in. The jQuery Migrate latest version is in the 3.5.x line, and its job is to restore and warn about deprecated jQuery APIs so older code keeps working while you clean it up.
Migrate is a diagnostic tool, not a permanent dependency. Run it with the development (non-minified) build in a test environment, open the console, and it will log every deprecated call your code makes. Fix those, then remove Migrate from production. Shipping jQuery Migrate to end users indefinitely is a common anti-pattern that adds weight and masks technical debt.
<!-- Development only: surface deprecation warnings, then remove -->
<script src="jquery-3.7.1.js"></script>
<script src="jquery-migrate-3.5.x.js"></script>
Why the Version Matters for Security
A dependency in maintenance mode still gets security fixes, which is exactly why staying current matters. jQuery UI has had XSS-class issues in the past in widgets like the datepicker and autocomplete, where insufficiently sanitized options could execute script. Running an old build means missing whatever fixes have shipped since.
The risk is amplified because jQuery UI often loads on pages that handle user input. If any widget option is populated from untrusted data without encoding, you have a potential XSS sink. Being on the jQuery UI latest version does not eliminate that; it just ensures you have the fixes that exist. You still have to encode data you pass into widgets.
Auditing Your Actual Usage
Before deciding what to do, find out what you really use. Many projects load the entire jQuery UI bundle to use one widget. Check which components you actually instantiate:
# Rough grep for jQuery UI widget usage in a codebase
grep -rE '\.(datepicker|autocomplete|dialog|sortable|draggable|tabs)\(' src/
If the answer is "we use the datepicker and nothing else," you have a clean opportunity to replace one widget with a native <input type="date"> or a small modern library and drop the whole dependency. An SCA tool will also tell you whether your pinned jQuery UI and jQuery core versions carry any known advisories, and flag them in CI so a stale copy does not linger unnoticed.
The Migration Question
Because jQuery UI will not modernize, most teams should treat it as a managed legacy dependency with an exit plan. That does not mean an urgent rewrite. It means:
- Pin to the jQuery UI latest version so you have current fixes.
- Use jQuery Migrate to inventory deprecated jQuery calls, fix them, and remove Migrate from production.
- Replace individual widgets with native HTML or lightweight modern components opportunistically, as you touch the surrounding code.
- Encode all untrusted data before passing it into any widget option.
This incremental approach retires the dependency over time without a risky big-bang rewrite, while keeping your security posture current the whole way.
When Staying Put Is Fine
Not every app needs to leave jQuery UI. An internal admin tool with a fixed feature set, no external users, and no roadmap can reasonably stay on the latest 1.14.x indefinitely, provided you keep the version current and encode inputs. The judgment call is exposure: the more untrusted traffic and the longer the expected lifespan, the more a migration plan is worth the effort.
FAQ
What is the jQuery UI latest version?
It is in the 1.14.x line, first released in August 2024. The project is in maintenance mode, so it receives compatibility and security fixes but no significant new features. The older 1.13.x line is no longer supported.
Is jQuery UI still safe to use?
It is safe to use if you stay on the latest version and encode any untrusted data before passing it to widgets. Older releases have had XSS-class issues in widgets like the datepicker, so running a current build matters.
What is the jQuery Migrate latest version and do I need it?
The jQuery Migrate latest version is in the 3.5.x line. Use it as a temporary diagnostic in development to surface deprecated jQuery API calls, fix them, and then remove Migrate from production rather than shipping it permanently.
Should I migrate off jQuery UI?
For public-facing, long-lived applications, plan an incremental exit by replacing individual widgets with native HTML or modern components as you touch the code. For stable internal tools, staying on the latest 1.14.x with current fixes is reasonable.