Validation and reportValidity()

<lightning-input
    label="Email"
    type="email"
    required
    value={email}
    onchange={handleEmailChange}>
</lightning-input>

<lightning-input
    label="Age"
    type="number"
    min="18"
    max="120"
    value={age}
    onchange={handleAgeChange}>
</lightning-input>

required, pattern, min, max, minlength, and maxlength are recognized directly by base input components, with no custom validation code needed for these common cases.

handleSubmit() {
    const isEmailValid = this.template.querySelector('[data-id="email"]').reportValidity();
    if (!isEmailValid) {
        return;
    }
    // proceed with submission
}

reportValidity() checks the field against its validation attributes and shows the browser/SLDS-styled error message inline if invalid, returning true or false. Calling it explicitly (commonly in a submit handler, before proceeding) is how validation is actually surfaced to the user — the attributes alone don't display anything until this is called.

handlePasswordConfirmChange(event) {
    const confirmInput = this.template.querySelector('[data-id="confirmPassword"]');
    if (event.target.value !== this.password) {
        confirmInput.setCustomValidity('Passwords do not match.');
    } else {
        confirmInput.setCustomValidity(''); // clears the custom error
    }
    confirmInput.reportValidity();
}

For rules the built-in attributes can't express — like comparing two fields against each other — setCustomValidity() sets a custom error message, and an empty string clears it. reportValidity() still needs to be called afterward to actually display the result.