jQuery Validation Plugin: drop-in client-side form validation

The problem it solves for teams that already have forms

Most validation libraries assume you build the form. This one assumes the form exists. You point it at a selector, and it reads the constraints already present in the markup, such as a required attribute, then attaches checking and message display to those fields. The README describes it as providing "drop-in validation for your existing forms", which is the whole pitch: no rewrite of the HTML, no schema file to keep in sync, no change to how the page is served.

That makes it a fit for server-rendered pages, admin panels, legacy applications with jQuery already on the page, and any codebase where a full framework migration is not on the table. It is a poor fit if you have never loaded jQuery and do not intend to. The plugin's peer dependency is jquery, declared in package.json as "^1.7 || ^2.0 || ^3.1 || ^4.0", so it is an addition to a dependency you must already carry, not a standalone library.

How validate() reads markup and decides what to check

The mechanism is a jQuery plugin call that binds to a form element. The README's minimal example selects a form and calls validate() with no arguments, and the plugin then walks the fields inside that form, applying built-in rules for the constraints it recognizes and any rules you pass in the options object.

Rules live in a rules map keyed by field name, and each rule can be a boolean or a function. The README's normalizer example shows the shape: a rule for username sets required to true and adds a normalizer, a function that receives the field value and returns a transformed value before the check runs. Inside that function, this refers to the corresponding DOM element, so you can read other attributes from the field if the rule needs context.

Error rendering is the other half. By default the plugin writes the message into a label element, and the README is explicit that this produces two label elements pointing at one input through the for attribute. It calls that valid HTML but notes inconsistent support across screen readers. Setting errorElement changes the element used for the message and, per the README, automatically adds ARIA attributes, with aria-describedby placed on the input and tied to the error element. That is a behavioural difference, not a cosmetic one.

Installing it and validating a first form

The README points to https://jqueryvalidation.org/ for prebuilt files, and the package is also published to npm as jquery-validation. The npm manifest sets main to dist/jquery.validate.js and lists the published files, which include the core bundle, the minified variant, additional-methods and the localization directory.

Install it alongside jQuery:

npm install jquery jquery-validation

Then include both scripts and call validate() on the form. This is the pattern the README gives, with the form markup and the two script tags in that order:

<form>
	<input required>
</form>
<script src="jquery.js"></script>
<script src="jquery.validate.js"></script>
<script>
    $("form").validate();
</script>

After that, submitting the form with the input empty should block submission and display an error message. If you load the plugin through a module loader instead, the README shows a requirejs form: define an array of "jquery" and "jquery.validate", then call $("form").validate() inside the factory.

To move the error out of the default label and into a span with ARIA wiring, pass errorElement:

$("#myform").validate({
  errorElement: "span"
});

The README's rendered output for that configuration shows the input gaining an aria-describedby attribute pointing at an id on the span that carries the message.

Two documented behaviour changes that break old assumptions

The README carries two notes that matter more than they look. The first concerns email validation. Since version 1.12.0 the plugin uses the same regular expression the HTML5 specification suggests for browsers. The project states it will follow that specification rather than diverge, and directs anyone who disagrees to raise it with the specification authors. If your application needs a different email rule, the README points to a custom method and to the documentation for adjusting built-in patterns. That is a deliberate refusal to be configurable by default, and it means upgrading can change which addresses your form accepts.

The second concerns the required rule. Since version 1.14.0 the plugin stopped trimming whitespace from the value of the attached element before checking it. A field containing only spaces now passes or fails differently than it did before that release. The normalizer option, available since v1.15.0, is the documented way to restore trimming, and the README's example uses $.trim inside the normalizer. Both changes are the kind that surface as production bugs rather than release-note reading, so the changelog.md in the repository root is worth checking against whatever version you pin.

A client-side library cannot be your only check

Everything here runs in the browser. The plugin can stop a form submission in a normal user session, and it can do nothing at all about a request sent directly to your endpoint. The README does not frame the library as a security boundary and does not claim server-side enforcement; it is described as client-side form validation in the package description. Treat the rules as an interface improvement that reduces round trips and gives faster feedback, and keep authoritative checks where the data is actually written.

The accessibility default is the second limitation, and it is documented rather than hidden. Out of the box, error messages land in a label alongside the field's own label, and the README states plainly that screen reader support for that arrangement is inconsistent. The fix is a one-line option, but it is opt-in, so a project that never reads the accessibility section ships the weaker default. That is a reasonable criticism to raise in review: the accessible path exists and is not the default.

A third constraint is architectural. Because rules are declared in JavaScript and keys are field names, renaming an input in the markup without updating the rules map silently detaches the rule. The plugin has no schema to validate against, so nothing warns you.

How it differs from HTML5 constraint validation

The most direct alternative is the browser's own constraint validation, using required, pattern, minlength and the rest, with no library at all. The difference is control. Native validation gives you a browser-rendered bubble whose text, position and timing you cannot style or replace, and behaviour varies between browsers. This plugin gives you an element you choose, a message you write, and a rules map you can extend with custom methods. It also lets you normalize a value before checking it, which native validation has no equivalent for.

The cost is the dependency and the code. Native validation is a few attributes; this is jQuery plus a plugin plus a rules object. If your constraints are simple and you can accept the browser's presentation, the attributes are less to maintain. If you need custom messages, cross-field rules, or a specific error element for accessibility, the plugin earns its weight. The README's own note about email validation is a useful illustration: the plugin deliberately tracks the HTML5 pattern, so on that rule the two approaches agree, and the plugin's value is in where and how the message appears.

Maintenance, licensing and what a version bump costs

The repository is not archived, and its last push was on 2026-06-29. The most recent release is 1.22.1 from 2026-02-18, following 1.22.0 on 2026-01-22 and 1.21.0 on 2024-07-17. The gap between 1.21.0 and 1.22.0 is roughly eighteen months, so the release cadence is not fast, and the package.json version reads 1.22.2-pre, meaning development continues past the last tagged release.

The build is Grunt-based. The npm test script runs grunt, prepublish runs grunt, and the README's instructions for unreleased files are to download or fork the repository, set up the build as described in CONTRIBUTING.md, and run grunt to produce files in the dist directory. The devDependencies list is pinned to specific older versions, including grunt 1.0.1 and grunt-contrib-uglify 1.0.1, so anyone building from source inherits that toolchain rather than a current one. Consumers who install the npm package get the prebuilt dist files and never touch Grunt, which is the common path.

The licence is MIT, stated in package.json and in the README's license section, with copyright attributed to Jörn Zaefferer. MIT permits commercial and closed-source use with the licence and copyright notice retained. That is a summary of what the files say, not legal advice; if your organisation has specific obligations around attribution, confirm them with whoever handles that.

Editorial conclusion

Adopt it when you already ship jQuery and want validation attached to markup you control, without a component framework or a bundler. Do not adopt it if you need server-side enforcement, a non-jQuery stack, or a library whose error output is accessible by default; the README states the default label-based error output has inconsistent screen reader support and points to errorElement as the fix. Before you commit, verify the version you install against the changelog, and check which localization file under dist/localization/ matches your locale, because the package.json files list ships those separately from the core bundle.

Frequently asked questions

Official sources

1. jquery-validation/jquery-validation on GitHub
2. License: MIT
3. Project website
4. README
5. Releases