HTML input types tell the browser what kind of data a form field expects, which shapes the on-screen keyboard, the built-in validation and the widget a visitor sees. Choosing the matching type is one of the cheapest ways to improve a form.
This guide sits inside the wider field of front-end web development, where markup, styling and scripting work together to turn a design into a working page.
How the type attribute works
Every field built with the input element carries a type attribute. According to MDN Web Docs, if the attribute is not specified, the default type adopted is text. A plain text field accepts anything, so the browser can offer no help: no tailored keyboard, no format check and no picker.
Switching to a more specific type hands part of that work to the browser. A visitor on a phone may get a keyboard with the at sign within reach, a numeric keypad or a calendar, depending on the type and the platform. The browser can also refuse an obviously malformed value before the form is sent. That check is a convenience rather than a security measure, because anyone can bypass it, so the server must still validate everything it receives.
Browsers that do not recognise a type fall back to a standard text field. Choosing a specific type is therefore a progressive enhancement: older software still shows a working field, and newer software shows a better one.
Text-like types: text, email, url, tel, search and password
The text-based types all hold a single line of characters, but each signals a different purpose.
- text suits names, free-form short answers and anything that has no better type.
- email is for email addresses. The input value is automatically validated to ensure that it’s either empty or a properly-formatted email address (or list of addresses) before the form can be submitted. Adding the multiple attribute lets the field accept a comma-separated list.
- url is for web addresses. It is validated in the same spirit: the value must be either empty or a properly-formatted URL before the form can be submitted.
- tel is for telephone numbers. MDN notes that mobile browsers may opt to present a custom keypad optimized for entering phone numbers. Phone number formats vary so much between countries that the type does not try to enforce one, so any pattern check has to be written deliberately.
- search is for search boxes. These are functionally identical to text inputs, but may be styled differently by the user agent, for instance with a clear button.
- password hides what is typed. The text is obscured, usually by replacing each character with a symbol such as the asterisk, so it cannot be read by someone looking over the visitor’s shoulder.
Two habits make these fields easier to use. First, give email and password fields an autocomplete attribute so password managers and browsers can fill them. MDN advises that, to allow the user’s password manager to automatically enter the password, specify the autocomplete attribute.
Numbers and choices: number, range, checkbox and radio
The number type looks like the obvious choice for any digits, but it is narrower than it seems. MDN spells out that the number type is not appropriate for values that happen to only consist of numbers but aren’t strictly speaking a number, such as postal codes in many countries or credit card numbers. Those values are identifiers, not quantities. A visitor never wants to nudge a postal code up by one with a stepper arrow, and leading zeros can be lost. For identifiers, a text field combined with the inputmode attribute is the better fit; MDN describes inputmode as a hint that provides a hint to browsers as to the type of virtual keyboard configuration to use when editing this element or its contents. That gives a numeric keypad without treating the value as a quantity.
Use the number type for genuine quantities such as the number of tickets, a quantity in a shopping basket or an age. The min, max and step attributes then describe which values are allowed. Number fields also come with built-in validation that rejects non-numerical entries.
The range type produces a slider. It is the wrong tool when precision matters: MDN states that because the widget is imprecise, it should only be used if the control’s exact value isn’t important. A volume control or a rough budget preference fits; an exact price does not. If the exact value is shown next to the slider, or a number field sits beside it, visitors can see what they selected.
Checkbox and radio controls handle fixed choices. A checkbox is described by MDN as a checkbox allowing single values to be selected/deselected, so it suits independent yes-or-no options such as agreeing to a newsletter. A radio button is a radio button, allowing a single value to be selected out of multiple choices with the same name value. Radios work when exactly one option must be picked from a short list, and giving the group a shared name is what makes them behave as a set.
Dates, colours, files and hidden values
The date type gives visitors a calendar picker and removes the guesswork about day-month order. The appearance differs by platform: MDN says the appearance of the date picker input UI varies based on the browser and operating system. What does not change is the submitted value, because the value is normalized to the format yyyy-mm-dd, whatever the visitor sees. That makes dates easy to process on the server. Related types handle a time, a local date and time, a month or a week.
The color type lets a visitor choose a colour. MDN explains that it lets a user specify a color, either by using a visual color picker interface or by entering the color into a text field in a CSS color value format. It is useful in design tools, theme settings and any form where a hex colour would otherwise have to be typed.
The file type lets a visitor select a file for upload. MDN describes it as a control that lets the user select a file, and the accept attribute narrows which kinds of file can be chosen. The accept attribute only guides the file dialog, so uploaded files still need checking on the server.
Finally, the hidden type carries data that visitors do not edit. It is a control that is not displayed but whose value is submitted to the server. Anything placed in a hidden field is visible to a visitor who inspects the page and can be altered, so it should never hold secrets or be trusted for decisions such as prices.
A quick reference table
| Type | Typical use | What the browser adds |
|---|---|---|
| Email address | Format validation, email-friendly keyboard on many phones | |
| url | Web address | Format validation |
| tel | Phone number | Phone keypad on many mobile browsers |
| number | A genuine quantity | Rejects non-numerical entries, optional stepper |
| range | Imprecise setting | Slider |
| date | Calendar date | Date picker, value submitted as yyyy-mm-dd |
| color | Colour choice | Colour picker |
| password | Secret value | Obscured characters, password manager support |
The summary above reflects the MDN Web Docs reference pages for the input element and its individual types.
Pairing input types with labels and semantic markup
The right type is only part of an accessible field. Every control still needs a visible label connected to it, because placeholder text disappears as soon as someone starts typing and is not a substitute. Grouping related radios and checkboxes inside a fieldset with a legend tells assistive technology which question the options answer. Good form markup is a direct application of semantic html, where elements are chosen for what they mean rather than how they look.
Layout comes after structure. Once the fields and labels are in place, CSS decides whether a form sits in a single column or spreads across a grid, and the flexbox vs grid comparison explains which layout method suits a row of aligned fields and which suits a full form grid.
A short checklist for choosing a type
- Ask what the value is. If it is a quantity, use number. If it is an identifier made of digits, use text with an appropriate inputmode.
- Ask which mobile keyboard would help most, and pick email, tel, url or search to get it.
- Prefer a date, color or file type when the platform offers a ready-made picker, but plan for browsers that fall back to a text field.
- Add autocomplete values to name, email, address and password fields.
- Keep server-side validation in place whatever the browser checks.
Frequently asked questions
What happens if a browser does not support an input type?
It treats the field as a standard text input, so visitors can still type a value. MDN documents this fallback for types such as tel and range, which is why a specific type is safe to use even when support varies.
Should a postal code or credit card field use the number type?
No. These are identifiers rather than quantities, and MDN advises against the number type for postal codes and credit card numbers. A text field with the inputmode attribute gives a numeric keypad without the stepper and without stripping leading zeros.
Is browser validation enough to protect a form?
No. Built-in checks on email, url and number fields improve the experience, but they can be bypassed. Every value must be validated again on the server.
Why does a date field look different in different browsers?
The picker is drawn by the browser and operating system, so its appearance varies. The submitted value is always normalized to the format yyyy-mm-dd, so the server receives a consistent format.
