Upgrading from 2.x

Most forms need no changes at all. The data-validation attribute API is unchanged, and $.validate() still does what it always did. The list below is everything that could behave differently.

Start here

Upgrade and run your forms. Most will simply work.
Check the console — every deprecation logs a warning naming its replacement.
Re-check anything using data-validation-strength; the scoring changed.
If you are on Bootstrap 4 or 5, add bootstrap: 5 to pick up the right class names.

Breaking changes

Password strength was rescored

This is the change most likely to affect an existing form. The old scoring awarded points for character composition — mixed case, digits, symbols — which NIST SP 800-63B rev 4 retired, because it rewards short predictable passwords over long ones.

Password	Old score	New score
`P@ss1!`	3	0
`Tr0ub4dor&3`	3	1
`abcdefghijklmnop`	2	0
`thequickbrownfox`	2	3
`correcthorsebatterystaple`	3	3

The attribute, the 0–3 scale and the thresholds are unchanged — only the scoring. Re-check any form that relies on a particular data-validation-strength level.

Validation follows the value, not the keyboard

Live re-validation is bound to input rather than keyup. A field corrected by paste, autofill, drag-and-drop, speech input or IME composition is now caught; before, it stayed marked invalid until the next keystroke.

If you wrote a custom validator that opted out with validateOnKeyUp: false, that is still honoured, but the option is now called validateOnInput.

`novalidate` is added by default

So the browser does not stack its own error bubbles on top of the plugin's messages. Set novalidate: false to go back. A novalidate attribute you wrote yourself is never removed either way.

Old-browser shims were removed

The placeholder and datalist shims are gone from the html5 module, as is the IE7 branch in the module loader. Every supported browser implements all three natively.

Deprecated

These still work and log a warning naming the replacement.

Deprecated	Use instead
`data-validation="complexity"`	`strength`, ideally with `breached`
`$.fn.validateOnKeyUp`	`$.fn.validateOnInput`
`$.fn.removeKeyUpValidation`	`$.fn.removeInputValidation`
`$.fn.validateForm`	`$.fn.isValid`
`validateOnKeyUp: false` on a validator	`validateOnInput: false`
`errorMessageCustom`	`submitErrorMessageCallback`
`data-validation-if-checked`	`data-validation-depends-on` (logic module)

Validator bugs fixed

Five validators regressed in 2.3.79. Each had a failing test in the suite that was never green; all are corrected.

Internationalised domains were rejected

The top-level domain had to be entirely alphanumeric, which turns away every IDN A-label since those contain hyphens — test.xn--fiqz9s (.中国) among them. TLDs that genuinely start or end with a hyphen are still rejected. This fixed URL validation too, which delegates to the domain validator.

The CVV validator never learned the card type

The credit card validator works out whether the form accepts American Express, which decides whether a CVV is three digits or four. That was being written to the card element and read from the CVV element — different elements, so it never arrived, and an amex-only form rejected valid four-digit codes. It now lives on the form, which both fields can see, and still cannot leak between two forms on one page.

`1.0236` was accepted as an integer

With decimal-separator set to ,, every dot was being stripped unconditionally — turning a dot used as a decimal point into 10236. Dots must now fall on a group boundary, so 1.234.567,89 is accepted and 1.0236 is not.

A date format without a day was always invalid

mm/yyyy is a legitimate format, but an absent unit was reported internally as -1 and then treated as an invalid zero. Absent units are now skipped, and come back as 1 so date arithmetic still works.

A malformed quoted email was accepted

"sasas-sdsd"[email protected] is not a valid address: RFC 5322 gives obs-local-part = word *("." word), and a quoted string followed straight by more text with no dot between them is not a valid word sequence. It is now rejected. Fully quoted local parts such as "sasas-sdsd"@monkey.com are still accepted.

New in 3.0 and 4.x

Addition	Where
Accessibility: `aria-invalid`, `aria-describedby`, live regions, focus management	Accessibility
`native` module — Constraint Validation API bridge	Modules
`breached` validator — Have I Been Pwned screening	Validators
Bootstrap 4 and 5 class-name presets	Configuration
`errorMessageTemplate` — documented since 2.x, honoured from 3.0	Configuration
Debounced async validation, and `aria-busy` instead of disabling the field	API
`observeDynamicFields` — a `MutationObserver` for fields added later	Configuration
Sentence templates with `Intl.PluralRules` plural forms	Localization
`localeNumberFormat` sanitizer, and `decimalSeparator: 'auto'`	Localization
ESM build, `exports` map and TypeScript declarations	Getting started

Packaging

The package now ships an exports map, an ESM build and TypeScript declarations. The UMD bundle is still there and main still points at it, so a <script> tag keeps working exactly as before.

JavaScript

// All three resolve correctly
import  jQuery from 'jquery-form-validator';
const   jQuery = require('jquery-form-validator');

HTML

<script src="form-validator/jquery.form-validator.min.js"></script>

Runtime script injection is gone

Modules used to be fetched by injecting a <script> tag whose path was discovered by sniffing the DOM. That broke under bundlers and under a strict Content-Security-Policy. $.formUtils.loadModules() still works for pages that rely on it; an import is now the better path.

A naming caveat worth knowing

Module and rule names cannot contain a hyphen

The plugin splits comma, space and hyphen separated lists with the same helper, so a module named constraint-api would be requested as two files and fail silently. This is why the Constraint Validation bridge is called native. It applies to any rule name you add yourself.