# How do you prompt an AI to build an HTML form with built-in validation?

Source: https://codelifter.com/forum/posts/how-do-you-prompt-an-ai-to-build-an-html-form-with-built-in-validation/
Site: CodeLifter Forum, category Vibe coding prompts
Published: 2026-11-13. Updated: 2026-11-13. Replies: 1.

## Question by CodeLifter editors (staff), 2026-11-13

Name the browser's own validation features in the prompt: input types such as `email` and `number`, the `required`, `minlength`, `maxlength`, `min`, `max` and `pattern` attributes, and `setCustomValidity()` only for rules HTML cannot express. Tell it to avoid a validation library, and to repeat every check on the server.

## Why does an assistant skip the built-in validation?

Ask for "a signup form with validation" and many assistants write a submit handler full of hand-made regular expressions and `if` statements, or add a library. That code duplicates work the browser already does. MDN's [Constraint validation guide](https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Constraint_validation) says that HTML5 added constraint validation so that "Basic, usual constraints can be checked, without the need for JavaScript, by setting new attributes; more complex constraints can be tested using the Constraint Validation API."

The fix is to say which layer does which job. A prompt that names the attributes gets attributes; a prompt that says "validate" gets whatever pattern the model has seen most often.

## Which attributes should the prompt ask for?

MDN's [client-side form validation tutorial](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation) lists the built-in features. This table turns them into prompt wording:

| Rule you want | Prompt wording | What MDN says it does |
| --- | --- | --- |
| Field must be filled | "Use the `required` attribute" | The field "needs to be filled in before the form can be submitted" |
| Length limits | "Use `minlength` and `maxlength`, not JavaScript length checks" | Sets the minimum and maximum length of text |
| Number range | "Use `type=number` with `min` and `max`" | Out-of-range numbers show as invalid |
| Email or URL format | "Use `type=email` and `type=url`, no hand-written email regex" | `typeMismatch` is true when the value is not in the required syntax |
| Custom format | "Use `pattern` for formats such as a product code" | A non-empty value that does not match makes the field `:invalid` |
| Rule HTML cannot express | "Use `setCustomValidity()` for this one rule only" | Marks the field invalid with your message |

One detail from the same tutorial is worth putting in the prompt: a `pattern` on an optional field does not make it required. "If empty, and the element is not required, it is not considered invalid."

## A prompt you can paste

```
Build a plain HTML signup form: name, email, age (optional), password,
confirm password. No JavaScript libraries.
- Use the browser's constraint validation first: required, type="email",
  type="number" with min="16" max="120", minlength="12" on password.
- Do not write regular expressions for email.
- The only JavaScript rule: confirm password must equal password. Use
  setCustomValidity() and clear it with setCustomValidity("") when valid.
- Style errors with :user-invalid, not :invalid, so empty fields are not
  red before the user has touched them.
- Every field has a visible <label>; keep the browser's error messages.
- Add a comment listing which checks the server must repeat.
```

The age numbers are an example; set the rules your form needs. Each line maps to a documented feature, so you can check the output against the docs rather than trusting it.

## What should the JavaScript part look like?

For the confirm-password rule, the output should be close to this:

```js
const pw = document.getElementById("password");
const confirmPw = document.getElementById("confirm");

function checkMatch() {
  confirmPw.setCustomValidity(
    confirmPw.value === pw.value ? "" : "Passwords do not match."
  );
}
pw.addEventListener("input", checkMatch);
confirmPw.addEventListener("input", checkMatch);
```

Check one thing in particular: the empty string. MDN's [setCustomValidity() page](https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/setCustomValidity) says "It's vital to set the message to an empty string if there are no errors. As long as the error message is not empty, the form will not pass validation and will not be submitted." Generated code that sets a message but never clears it produces a form that can never be sent.

## Which generated mistakes break validation quietly?

Read the output for these, all described in MDN's Constraint validation guide:

- **`novalidate` on the form.** Assistants add it to show custom messages. The guide says that with it "interactive validation of the constraints doesn't happen", so your script must then check everything itself.
- **`form.submit()` in a handler.** The guide says calling `submit()` "doesn't trigger a constraint validation" and sends the data anyway. Use a real submit button, or `requestSubmit()`.
- **Values set from code.** `minlength` and `maxlength` "are only checked on user-provided input", not when a script fills the field.
- **Styling with `:invalid`.** Required fields match it as soon as the page loads. MDN's [:user-invalid page](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:user-invalid) describes a selector that applies only "after the user has interacted with it", and marks it available across browsers since November 2023.

## Is browser validation enough on its own?

No, and the prompt should say so. MDN's tutorial is blunt: client-side validation "*should not be considered* an exhaustive security measure", because it is "too easy to bypass, so malicious users can still easily send bad data through to your server." The Constraint validation guide lists how: editing the HTML in developer tools, hand-crafting an HTTP request, or filling fields from a script. Browser validation is for the person filling in the form; the server check is for everything else.

Checked on 12 November 2026.

Labels, error text and focus handling are a separate job, covered in the [accessible forms thread](/forum/posts/how-do-you-get-a-coding-assistant-to-write-accessible-html-forms/). For how to structure prompts like the one above, see CodeLifter's guide on [how to write a coding prompt](https://codelifter.com/prompts/how-to-write-a-coding-prompt/).

## Short version

- Name the attributes (`required`, `type`, `minlength`, `min`, `max`, `pattern`) instead of asking for "validation".
- Keep JavaScript for rules HTML cannot express, through `setCustomValidity()`, and clear it with an empty string.
- Watch for `novalidate` and `form.submit()`, which switch the browser's checks off.
- Style errors with `:user-invalid` so fields are not red before anyone types.
- Repeat every check on the server.

## Reply 1 by CodeLifter editors (staff), 2026-11-13

**Can you change the wording or look of the browser's error bubbles?** The wording, yes; the look, no. MDN's [form validation tutorial](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation) names two drawbacks of the built-in messages: "There is no standard way to change their look and feel with CSS", and they "depend on the browser locale, which means that you can have a page in one language but an error message displayed in another language."

To change the wording while keeping the bubble, call `setCustomValidity()` with your own text when a specific check fails, and clear it otherwise. MDN's example does this for an email field by checking `email.validity.typeMismatch`. The [setCustomValidity() page](https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/setCustomValidity) adds that the message is not shown straight away: it appears when the user tries to submit, or when you call `reportValidity()`.

To control the look as well, the tutorial's later example adds `novalidate` to the form, writes messages into a `<span>` next to each field, and sets `aria-live="polite"` on it so the message "will be presented to everyone, including it being read out to screen reader users." If you prompt for that version, say so explicitly, because your script then has to check every field on submit: `novalidate` turns off the browser's own blocking.

---
Cite as: CodeLifter Forum, "How do you prompt an AI to build an HTML form with built-in validation?", https://codelifter.com/forum/posts/how-do-you-prompt-an-ai-to-build-an-html-form-with-built-in-validation/, accessed 2026-11-14.