What do you gain by setting an HTML <input> to type="email" instead of leaving it as type="text"?

## What the type attribute actually is The `type` attribute on `<input>` is not a label for humans; it selects a *state* the browser implements. Each state comes with its own value grammar, its own rendered control, its own virtual-keyboard hint, its own implicit ARIA role, and its own built-in validity check. Choosing the right one is the cheapest accessibility and UX work available in HTML, because everything above is behaviour you would otherwise write yourself. `type="email"` is one of the text-shaped states. The rendered control is still a single-line text box, so visually nothing changes, which is why juniors often conclude it "does nothing". ## 1. Built-in shape validation With `type="email"`, a value that does not match the spec's valid-email-address production makes the control invalid. On submit the browser blocks the form and shows a native bubble; no JavaScript is involved. ```html <form> <label for="em">Email</label> <input id="em" type="email" name="email"> <button>Sign up</button> </form> ``` The grammar is deliberately loose. Exactly one `@`, no spaces, something on each side — and that is roughly it. `a@b` is **valid**: the specification does not require a dot in the domain part, because plenty of intranet hosts have none. `user@@example.com` and `user [email protected]` are invalid. An empty field is valid unless it is marked required, since "absent" and "malformed" are different states. The crucial framing for an interview: this is a *shape* check. It cannot tell you the mailbox exists, the domain resolves, or the user owns it. The only real verification is sending a message and having the user act on it. Treating `type="email"` as verification is a genuine product bug, not a nitpick. ## 2. Input affordances on touch devices On phones and tablets the type drives which virtual keyboard appears. An email keyboard puts `@` and `.` on the primary layer and typically removes the space bar, which is a measurable difference in typing errors on a signup form. Nothing analogous happens with a hardware keyboard — the benefit is real but device-dependent. Browsers and password managers also feed the type into their autofill heuristics when deciding whether a field wants a saved address. The type alone is a weak signal compared with an explicit autocomplete token, but a field typed as `text` gives the browser nothing to go on. ## 3. Semantics for assistive technology `type="email"` maps to the same implicit role as a plain text box, so a screen reader still calls it an edit field. What changes is that the platform knows the expected value kind, and the browser's own validation message is announced when submission is blocked. You get platform-quality error messaging without authoring a live region. ## The multiple attribute Adding `multiple` changes the grammar rather than the widget: ```html <input type="email" name="invites" multiple> ``` The field now accepts a comma-separated list, each entry validated independently, with surrounding whitespace stripped. This is the correct markup for an "invite teammates" field — no chip component required for a first version. Without `multiple`, a comma makes the value invalid. ## What it does not give you It gives you no styling. It gives you no normalisation — the browser does not lowercase the value or trim a trailing dot for you, so any canonicalisation is still yours to do. It gives you no control over the wording or position of the native error bubble, which is why teams that need branded errors turn the browser's own validation off and render their own messages, keeping the type for the keyboard and semantics. And it is a client-side convenience only: anything arriving at a server is untrusted regardless of what the markup said. ## How to answer this in an interview Say what you get (validation shape, keyboard, autofill signal, platform semantics), then immediately volunteer the two limits — `a@b` passes, and existence is unproven. Candidates who list only the benefits sound like they have read a tag reference; candidates who name the loose grammar sound like they have shipped a signup form.