HTML form controls expose both checkValidity() and reportValidity(). What does each one do, what do they have in common, and when would you call one over the other?

## The two calls Constraint validation exposes two methods on every form-associated control and on `<form>`: - `checkValidity()` — runs the constraints, fires an `invalid` event at each control that fails, returns `false` if anything failed and `true` otherwise. No UI. - `reportValidity()` — does all of the above and then reports the first failure to the user: the browser's own message bubble appears next to the control, and focus (and scroll) moves there. The naming is the mnemonic: *check* is silent, *report* talks. ```js const form = document.querySelector('#signup'); const email = form.elements.email; email.checkValidity(); // true/false, nothing visible form.reportValidity(); // same answer, plus a bubble on the first bad field ``` ## What both of them do that surprises people They are not pure predicates. Both dispatch an `invalid` event at every control that fails, so a listener runs as a side effect of merely asking. That event does not bubble, so listeners go on the controls themselves (or use capture on an ancestor). This is exactly what makes a per-field pattern possible: listen for `invalid` on each input, and in that listener render your own message. ```js for (const el of form.elements) { el.addEventListener('invalid', (event) => { event.preventDefault(); // suppress the native bubble showMyError(el, el.validationMessage); }); } ``` Canceling the `invalid` event suppresses the browser's default report for that control, which is one way to keep the API's validation while owning the presentation. ## Form-level versus control-level Called on a `<form>`, either method walks every submittable control in the form and aggregates the result: `false` if any single one fails. Called on one control it considers only that control. Controls that do not participate — `disabled`, `readonly`, `type="hidden"`, buttons, anything inside a `<datalist>` — are skipped; their `willValidate` property is `false` and their `checkValidity()` returns `true` because there is nothing to violate. ## Neither one submits A frequent bug is expecting `reportValidity()` to submit when everything passes. It does not. It is purely a validation call. In a custom submit flow you write both halves: ```js form.addEventListener('submit', (event) => { if (!form.checkValidity()) { event.preventDefault(); renderErrors(form); } }); ``` And note the subtlety in that snippet: with a normal form the browser has *already* validated before dispatching `submit`, so this handler only ever sees a valid form. The pattern is written that way for forms carrying `novalidate`, where the browser's automatic pass is switched off but the API keeps working exactly as before. ## Choosing between them Use `checkValidity()` when the answer feeds a decision rather than the user: deciding whether to enable a button, whether to send an availability request, whether to advance a wizard step. Use `reportValidity()` when the user has just tried to proceed and you want the browser's built-in messaging without writing any UI — it is a genuinely good default for internal tools and prototypes, because it is free, localized by the browser, and focuses the offending control. Use neither for presentation if you are building a design system: there `checkValidity()` plus the `validity` flags and `validationMessage` string give you the data, and your own markup gives you the message, which you can style, place inline, and reference from the field. `reportValidity()` would fight that by popping a native bubble the moment you called it. ## Reading the message text Alongside the methods, every control exposes `validationMessage`: the string the browser *would* display, in the browser's UI language, or an empty string when the control is valid. It is useful as a fallback, but its locale follows the browser rather than the page, which is a common reason teams write their own copy instead. ## What weak answers sound like "`checkValidity()` checks one field and `reportValidity()` checks the whole form" — no, both work at either scope. "`reportValidity()` submits if valid" — it never submits. "Calling `checkValidity()` has no side effects" — it fires `invalid` events, which is precisely how the per-field error pattern is built.