Text controls

Pick the control that matches the value the person is typing. The browser gives you a lot for free when you do.

Here are three common ones:

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">

<label for="website">Website</label>
<input id="website" name="website" type="url">

<label for="message">Message</label>
<textarea id="message" name="message" rows="6"></textarea>

The type changes how the browser behaves. On a phone, type="email" shows a keyboard with @ and . on it. On submit, the browser checks the value looks like an address and refuses to send flavio on its own. type="url" does the same for URL-shaped values.

A textarea is the only one of these that accepts multiple lines. rows sets the visible height. The person can still type more than six lines and scroll.

What the type doesn’t do

The browser’s check is loose on purpose. ada@localhost passes as an email. https://this-site-does-not-exist.test passes as a URL.

So the type proves nothing about the world. It doesn’t prove the address exists, that the URL is safe to fetch, or that the message is acceptable. The server receives strings and has to apply the real rules.

Passwords

Use type="password" when the text should be hidden on screen:

<label for="password">Password</label>
<input id="password" name="password" type="password" autocomplete="current-password">

The dots are visual only. The value travels as plain text inside the request, and HTTPS is what protects it on the way. On the server, never store it as is. Run it through a password-hashing function like Argon2 or bcrypt and store the hash.

Search and telephone

type="search" and type="tel" mostly change input behavior. Search fields get a clear button in some browsers. Telephone fields get a numeric keyboard on phones.

Neither validates the format, and that’s a good thing for tel. Phone numbers vary a lot between countries. Don’t add a narrow pattern unless your service accepts exactly one format.

Let the browser autofill

Add autocomplete wherever the browser can safely help. email, name, current-password, new-password, and postal-code are the values I use most. They cut typing and make forms much faster to complete on a phone.

Test your text controls on a real phone, or with device emulation in DevTools. Look at which keyboard appears and what happens on submit with a bad value. Desktop appearance tells you very little about how a form feels.