HTML Input Types

What are the HTML input types?

The type attribute on an input element selects what kind of control the browser renders, from a plain text box to a date picker, a colour swatch or a file chooser. The HTML Standard defines 22 keywords, and each one names a state: type=email is the Email state, type=datetime-local is the Local Date and Time state, and so on.

It is an enumerated attribute, which means the specification has to say what happens when the value is something it does not recognise. It says this: the attribute's missing value default and invalid value default are both the Text state. That single sentence is the reason this page exists.

Read it carefully and it covers two different situations at once. A browser that has not implemented a type falls back to a text field — and so does a keyword you simply spelled wrong. Both produce an ordinary text box, with no error, no console warning and nothing on screen to tell them apart.

How to use it

1. Type a keyword into the box to check it. It starts on a misspelling, because that is the case worth seeing first. The tool says whether the specification defines the keyword and, when it does not, what it will silently become instead.
2. Read the table. All 22 keywords with the state name the specification gives each, grouped by what kind of control they are. The list is complete rather than a selection.
3. Look at the last column. That is measured in the browser you are reading this in, not copied from a compatibility table. It asks an input element for each type and reads back what it says it is.

Why a support table is the wrong shape for this question

Most pages answering which browsers support type=date give you a grid of versions. That grid is out of date the day it is published, it cannot know which browser you are using, and it certainly cannot know about the one your users have. It answers a question about the world when you wanted an answer about your machine.

The fallback rule makes a better answer possible. Because an unsupported type resolves to the Text state, you can ask an element directly: set the property, read it back, and if it comes back as text the browser did not take it. Three lines, no library, no version sniffing, and the answer describes the browser actually running the code.

That is what the last column does here, and it is why the column says checking your browser until the page has loaded rather than rendering a guess on the server. The server has no idea what you are using; pretending otherwise would be the same mistake the grid makes.

There is one row the check cannot decide, and the table says so rather than hiding it. Asking for text returns text whether or not anything else is supported, so that row is marked by definition. Every other row is a real measurement.

The typo you will never see

Of the two things the fallback rule covers, the misspelling is the one that bites hardest, because it is entirely your own doing and it looks exactly like success. Write type=dat instead of type=date and you get a text field. Write type=nubmer and you get a text field. Write type=datetime, which was a real keyword once and was removed from the standard, and you get a text field.

Nothing complains. The page renders, the form submits, the field accepts input. What you lose is everything the correct keyword would have given you: the date picker, the numeric keyboard on a phone, the built-in validation, the constraint that stops a nonsense value being submitted at all. On a desktop browser during development, a text field where a date picker should be is easy to miss for weeks.

The keyword box at the top of this page exists for that. Paste in what you actually wrote, and it tells you whether the specification has ever heard of it. It is a small check, and it is the only one available, because by design the browser will not tell you.

Honest limitations

Support is not one question. A browser can accept a type, render a control for it and still behave differently from another browser that also accepts it — the date picker's appearance, whether a step attribute is honoured, how a value is formatted for the user. This page answers the first question only: did the browser take the type at all. That is the question the fallback rule makes answerable, and it is not the whole story.

The table also cannot tell you about a browser that is not the one you are using. If you need to know what your visitors get, the measurement has to happen in their browsers, which is a different job from a page like this one.

Two columns from the specification's own table are missing here on purpose. It also lists a data type and a control type for each keyword, and when those were extracted the columns drifted by one on at least one row — the file entry came out describing a MIME type where the control type belongs. Publishing a table that looks right and is wrong is worse than publishing a shorter one that is right, so the keyword and the state name are all this carries.

Finally, the specification changes. Keywords have been added over the years and at least one has been removed, so a list is a snapshot of the standard as it stands. The fallback rule is the part that has not moved, and it is the part worth remembering.

Why is it free?

The list is static and the check runs in your browser. There is no server involved, so there is nothing to bill for and no account to create.

Nothing is uploaded and nothing is stored. Reload the page and it has forgotten what you typed.