HTML5 forms input types

by .

In the first article in this series we looked at the history of HTML5 forms and many of the new attributes available to us. In this second and final part of the series, we’ll look at the new input types available in HTML5. As we’ll see, these new features will go a long way toward making your life easier while delivering a delightful user experience. The best thing about all this? You can start using them now.

This is article is an excerpt from Chapter 6 of Beginning HTML5 and CSS3: The Web Evolved by Christopher Murphy, Oli Studholme, Richard Clark and Divya Manian, published by Apress.

Note: As this article is a book excerpt, browser renderings of attributes and input types may have altered since the screenshots were taken. Additionally, browser support may have increased since publication so please refer to the links at the end of the article for the current state of browser support.

New input types

HTML5 introduces no less than a baker’s dozen (yes, that’s 13!) new input types for forms. We’re going to take a brief look at each of them and explain why you should be using them right now. These new input types have dual benefits: using them means less development time and an improved user experience. The new input types we’ll be looking at are:


In rendering terms, the email input type is no different than a standard text input type and allows for one or more e-mail addresses to be entered. Combined with the required attribute, the browser is then able to look for patterns to ensure a valid e-mail address has been entered. Naturally, this checking is rudimentary, perhaps looking for an @ character or a period (.) and not allowing spaces. Opera 9.5+, Firefox 4+, Internet Explorer 10 and Chrome 5+ have already implemented this basic validation. The browser goes as far as presenting the user with an error message (see Opera in Figure 3) if the e-mail address entered isn’t valid. You can style the field for when an value is entered using the :valid, :invalid or :required pseudo class (assuming you have the required attribute on the input) just like Locum Dr. Peter explained.

<input type="email" name="email" required>
Screenshot of an email input field in Opera with an error message stating 'Please enter a valid email address' with 'gordo' written in the field
Figure 3. Opera e-mail address error messaging

The specification details that one or more e-mail addresses are allowed. This means that the multiple attribute could be used with type="email" too.

Pretty cool, huh? Again, this highlights how HTML5 forms help to cut down the amount of JavaScript that you have to write when carrying out form validation.

There’s always a catch, though, right? At the time of writing, there is an internationalization issue with type="email". When using it with double-byte internationalized domain names, the browsers invalidate them; so this example

<input type="email" name="email" value="gordo@日本.jp">

isn’t valid in Firefox, Safari, or Chrome (there is no issue in Opera). However, a workaround has been created by Kyle Barrow that uses type="text" with the pattern attribute, as shown here:

<input type="text" name="email" value="gordo@日本.jp" pattern="[^ @]*@[^ @]*">

An alternative solution is to continue using type="email" with the formnovalidate attribute on the submit button, as follows. This ensures that no validation will be carried out on form submission, which may or may not be suitable for your needs.

<form action="process.php">
<label for="email">Email:</label>
<input type="email" name="email" value="gordo@日本.jp">
<input type="submit" formnovalidate value="Submit">
Or you could use the novalidate attribute on your form, like so:

<form action="process.php" novalidate> <label for="email">Email:</label>
<input type="email" name="email" value="gordo@日本.jp">
<input type="submit" value="Submit">

Internationalization issues aside, remember how we said there are dual benefits to HTML5’s input types—less development time and better user experience? Let’s go back and look at the iPhone once more, as shown in Figure 4.

Screenshot of an iPhone with dynamic keyboard and the action button saying 'Go' when focussed on the email input field
Figure 4. The iPhone displays a custom keyboard when using type=”email”.

Did you notice it this time? No? Look at the keyboard again. That’s right, the keyboard is different. There are dedicated keys for the @ and . characters to help you complete the field more efficiently. As we discussed with type="search", there is no downside to using type="email" right now. If a browser doesn’t support it, it will degrade to type="text". And in some browsers, users will get a helping hand.


The url input type, as you might expect, is for web addresses. You can use the multiple attribute to enter more than one URL. Like type="email", a browser will carry out simple validation on these fields and present an error message on form submission. This is likely to include looking for forward slashes, periods, and spaces, and possibly detecting a valid top-level domain (such as .com or Use the url input type like so:

<input type="url" name="url" required>

Again, we’ll take a look at how the iPhone renders type="url". As you can see in Figure 5, it has again updated the onscreen keyboard to ensure that completing the field is as simple as possible for the user by swapping the default space key for period, forward slash, and .com keys. (To access more endings like .org and .net, tap and hold the .com key.)

Screenshot of an iPhone with dynamic keyboard and the action button saying 'Go' when focussed on the URL input field
Figure 5. type=”url” activates a URL-specific keyboard on the iPhone.


tel differs from email and url in that no particular syntax is enforced. Phone numbers differ around the world, making it difficult to guarantee any type of specific notation except for allowing only numbers and perhaps a + symbol to be entered. It’s possible that you can validate specific phone numbers (if you can guarantee the format) using client-side validation. type="tel" is marked up as follows:

<input type="tel" name="tel" id="tel" required>

Once more, the iPhone recognises type="tel", only this time it goes one step further and completely changes the keyboard to the standard phone keyboard, as shown on the left in Figure 6. In addition to the iPhone, some Android devices (such as HTC Desire, shown on the right in Figure 6) also display a numeric keyboard for type="tel". That’s pretty handy, don’t you think? Nice, big keys for entering a phone number help you to get that big, nasty form completed quickly.

Screenshot of an iPhone and Android device with dynamic keyboard changing to a number input when the user is focussed on a tel input field
Figure 6. type="tel" on the iPhone and some Android devices dynamically changes the keyboard to a numeric keypad. (Android screenshot provided by Stuart Langridge).


number, as you might expect, is used for specifying a numerical value. As with the majority of these new input types, Opera was the first to implement type="number". It, Safari, and Chrome render the input as a spinbox control (see Figure 7) whereby you can click the arrows to move up or down. Or if you prefer, you can type directly into the field. Firefox, on the other hand, renders the field like a standard text box. Support for type=”number” is in IE 10 also, although if you enter a non-numerical character the field empties when focus is lost and no feedback is provided to the user.

Screenshot of the Opera browser rendering of a number input field for 'showe size' the value is 9 and there are up and down arrows to the right of the field.
Figure 7. type="number" in Opera

With the additional attributes min, max, and step we can change the default step value of this spinbox control as well as set minimum, maximum, and starting values (using the standard HTML value attribute). This example shows how these attributes work:

<input type="number" min="5" max="18" step="0.5" value="9" name="shoe-size">

In this example, min represents the minimum value the field will accept, and max represents the maximum value. If we reach the maximum or minimum value, the appropriate arrow on the spinbox control will be greyed out so you can no longer interact with it. step is the increment that the value should adjust up or down, with the default step value being 1. This means we can include negative values or step up in increments of 0.5 or 5. value is that attribute you’re used to from previous versions of HTML. Each of the attributes are optional, with defaults being set if they aren’t used.

In contrast to Opera’s implementation, the iPhone (Figure 8) and some Android devices (such as HTC Desire, shown on the right in Figure 6-13) simply render the field as a standard text box but optimize the keyboard for easy input.

Screenshot of an iPhone and Android device with dynamic keyboard changing to a number input when the user is focussed on a number input field
Figure 8. type="number" on iPhone and Android HTC Desire (Android screenshot provided by Stuart Langridge)

To make the iPhone render with the standard telephone keypad as we saw for type="text" Chris Coyier, of CSS Tricks devised a little hoax you can use. Rather than using type=”number”, use a standard type="text" input and add a pattern attribute that accepts only numbers, as shown below. This solution isn’t ideal but if you think it could be useful, Chris has put a short video together showing it in action.

<input type="text" pattern="[0-9]*" name="shoe-size">

Chris’ technique may soon become absolete though with the introduction of the inputmode attribute. The attribute, recently added to the specification will allow users to specify the type of input mechanism that is most useful for users. When implemented, you will be able to choose between numeric, latin, email, or kana input modes.


The range input type is similar to number but more specific. It represents a numerical value within a given range. Why the difference, I hear you cry? Because when you’re using range, the exact value isn’t important. It also allows browsers to offer a simpler control than for number. In Opera, Safari, Internet Explorer 10 and Chrome, type="range" renders as a slider (see Figure 6-14). When moving the slider in IE 10 a tooltip appears showing the current value. Additionally, in Opera, if the CSS defines the height greater than the width, the slider control will be rendered vertically as opposed to the standard horizontal rendering.

The following code shows how we might mark up our skill level on a scale of 1 to 100 by setting the min and max attributes (see Figure 9). We can also set the starting point for range using the value attribute.

<input id="skill" type="range" min="1" max="100" value="0">
Screenshot of the range input type for Flying Skill level as rendered by Opera.
Figure 9. type="range" in Chrome

Dates and times

If you’ve ever booked tickets online, you will have come across date pickers to help you quickly and easily choose the date you require. Perhaps you’ve even implemented a date picker on your own website. Generally, this is done using a JavaScript library such as jQuery, Dojo, or YUI. It can be a pain when you need to load a whole library and associated plug-ins just to implement a simple date picker. Well, with HTML5 we get that functionality baked into the browser. Not only that, but we don’t have to stop at just electing a single date; we can select a week, month, time, date and time, and even date and time with a time zone using the different input types. The markup is pretty straightforward.

<input id="dob" name="dob" type="date">

You can go a step further by using the min and max attributes to ensure the user can only choose from a specified date range.

<input id="startdate" name="startdate" min="2012-01-01" max="2013-01-01" type="date">

As with many of the other form implementations, Opera leads the way (support in other browsers is varied). Let’s take a look next at how browsers render these input types.


Figure 10 shows Opera 10.5’s rendering of type="date".

Screenshot of the date input type rendered by Opera. There is a dropdown for the date and a calendar widget shown.
Figure 10. type="date" in Opera 10.5

These date pickers aren’t restricted to desktop devices; some Blackberry devices and Chrome for Android render its internal date picker when used with type="date" (see Figure 11).

Screenshot of the date input type as rendered on a Blackberry. There are three spinners, one for day, one for month and another for year.
Figure 11. type="date" on Blackberry (screenshot provided by Terence Eden)


Next up, Figure 12 shows type="month", which might, for example, be used for a credit card expiry date.

<input id="expiry" name="expiry" type="month" required>
Screenshot of the month input type rendered by Opera. There is a dropdown for the date and a calendar widget shown with the current month highlighted.
Figure 12. type="month" in Opera 10.5


You can also drill down to type="week". Notice how Opera highlights a specific week using the same date picker control, as shown in Figure 13.

<input id="vacation" name="vacation" type="week">
Screenshot of the week input type rendered by Opera. There is a dropdown for the date and a calendar widget shown with the current week highlighted.
Figure 13. type="week" in Opera 10.5


You can see in Figure 14 that type="time" renders a spinbox similar to that used earlier for selecting the precise time.

<input id="exit-time" name="exit-time" type="time">
Screenshot of the time input type rendered by Opera. There is an input with a value of 14:10 and up and down arrows to the right of the input.
Figure 14. type="time" in Opera 10.5


We can combine the date and time by using type="datetime" for specifying a precise time on a given day, as shown in Figure 15.

<input id="entry-day-time" name="entry-day-time" type="datetime">
Screenshot of the datetime input type rendered by Opera. There is a dropdown for the date and a calendar widget shown with the current day highlighted. There is an input with a value of 12:08 and up and down arrows to the right of the input along with the text 'UTC'.
Figure 15. type="datetime" in Opera 10.5


Finally, Figure 16 shows that we can achieve slightly more granular control by selecting a precise time on a given day with a local time zone variation using type="datetime-local".

<input id="arrival-time" name="arrival-time " type="datetime-local">
Screenshot of the datetime-local input type rendered by Opera. There is a dropdown for the date and a calendar widget shown with the current day highlighted. There is an input with a value of 17:08 and up and down arrows to the right.
Figure 16. type="datetime-local" in Opera 10.5

Date and time caveats

There are two caveats with these implementations. First, with the current implementation, it isn’t possible to type a date into the field (in all browsers). The date picker is keyboard accessible, though. However, we can foresee a potential issue; if implemented on a form that a data entry clerk regularly completes, they are likely to be quicker at typing the date than tabbing through with the keyboard or selecting from a date picker. Second, it isn’t possible to style the look of the date picker. We tend to think that this is a good thing, as users will receive a common experience across all websites they visit (provided they use the same browser all the time). Undoubtedly, though, corporations will require a branded date picker. Safari 5 and Chrome 5 have implemented these input types, but, unfortunately, they aren’t very user friendly. Dates have to be entered in the same format as the time element that we met earlier in the book. So for dates, the format would be YYYY-MM-DD, and for dates with time, a user would have to enter YYYYMM-DDT00:00Z, which is not very friendly at all.

As with the other new input types, if a browser doesn’t recognize them, it will simply default back to type="text" and let the user continue to use your JavaScript date picker.


The color input type is pretty self-explanatory: it allows the user to select a color and returns the hex value for that color. It is anticipated that users will either be able to type the value or select from a color picker, which will either be native to the operating system or a browser’s own implementation. Opera 11 has implemented type=”color” with a simple color picker that offers a number of standard color choices or the option to select Other, which brings up the operating system color picker (shown on the right in Figure 17).

<input id="color" name="color" type="color">
Screenshot of the color input type as rendered by Opera. There is a colour dropdown which when clicked shows a range of colours with an 'other' button. The right shows the dialog box opened when the user clicks 'Other' which is a standard operating system color dialog.
Figure 17. type="color" in Opera on the left and the result of clicking Other shown on the right

In contrast, certain Blackberry devices have implemented the color input type that renders a color picker, as shown in Figure 18.

Screenshot of the color input type as rendered on a Blackberry. There is a colour spectrum with a hue box and a color preview alongside an 'OK' button.
Figure 18. type="color" on Blackberry (screenshot provided by Terence Eden)

Input types summary

By using HTML5’s new form input types right now, we can enhance the user’s experience, future-proof our site, and make our life as developers easier. Obviously, we can’t just leave the browsers that don’t support all these new features hanging, and in Chapter 6 of Beginning HTML5 and CSS3 we take a look at how to detect support for these form features using JavaScript.

You can find a dummy form, using some of the examples we’ve shown in this article at our HTML5 forms demo page.

We’ve hinted throughout the article at which browsers have support for HTML5 forms input types and attributes. With new versions of browsers being released at an ever-increasing rate, it can be difficult to keep up with what is or isn’t supported. If you want to keep an eye on the current progress, we suggest visiting When can I use … or FindMeByIP or Wufoo’s HTML5 forms research.

If you missed the first article in this series on HTML5 forms, why not read a brief History of HTML5 forms and learn all about the new attributes introduced.

Cover image of Beginning HTML5 and CSS3: The Web Evolved.

This is article is an excerpt from Chapter 6 of Beginning HTML5 and CSS3: The Web Evolved by Christopher Murphy, Oli Studholme, Richard Clark and Divya Manian, published by Apress.

21 Responses on the article “HTML5 forms input types”

  • Chris Adams says:

    <input type="email"> not handling punycode is an embarassing gaffe. Fortunately, it appears that Firefox has been corrected since the original note was added as works in FF19 ( suggests support goes back as far as FF13).

    Unfortunately, WebKit doesn’t appear to have moved at all in the last couple years:

  • Dave says:

    This week I implemented upload image

  • So what’s the current status of the i18n problems with number inputs? Decimal point vs. decimal comma etc. Page language vs. browser language. I think I read somewhere that Chrome had made some progress there, but I’m not sure. What about other browsers? What about the standard itself?

  • Michael says:

    Great overview, thanks.

    When using type=”url” you should however be aware of that at the moment different browsers have different validations and that you better should not use it like it is . I explained it in an article.

    As I couldn’t really found out why browsers eg accept url: but not I would be really interested if you know why?


  • H Max says:

    Very comprehensive, enlightening and helpful article. Fine, fine work. Thanks for giving back.

  • Egor Kloos says:

    Dates, time and numbers have different formatting based on language and location. Implementation for these input types is far from trivial. A common issue I’ve run into is that users have an OS in one language and a browser in another. Making certain input types work consistently can be a real pain and sometimes not worth the effort to implement. Hopefully, as these inputs mature, it will become easier and more predictable.

  • A common issue I’ve run into is that users have an OS in one language and a browser in another

    And then the page is in a third language. Or perhaps it’s in two or more languages at the same time, having text in several languages labeling each input… What to do? What to do?

  • Egor Kloos says:

    Indeed, multiple languages, as Bertilo states, leaves us with a number of issues with no clear solution. What to do?
    When that happens you realise that the solution is compromise. The good old ‘text’ input with progressive enhancement is often your best bet. Well, that’s my current approach. Non universally formatted HTML5 input types like date and number are simply not ready for the real world yet. Why not have a format attribute alongside the pattern attribute?

  • @Chris, thanks for the note.

    @Bertilo, you’re right. I’ve seen some discussion around this but I’m not exactly where it’s at currently.

    @Michael, great tip and thanks for the article link.

    @Egor, you make some great points and I agree with you that some of the input types aren’t quite ready for production just yet without a bunch of workarounds.

  • Sam says:

    In Chrome 24, you can use the keyboard to quickly and easily type in dates. You can also use the up and down keys to increment and decrement each value (day, month, year). Pretty useful for those who know how to use a keyboard.

  • Amit Asthana says:

    I want to see like dd/mm/yyyy format, when i am desining in chrome input type=”date”, I am getting mm/dd/yyyy, this is what i don’t want, then i would have to chose the html 4 way, which I don’t want. If anyone can help me will be good enough.

    Thanks in advance.

  • Sven says:

    Can anyone comment on whether the ‘required’ attribute is behaving any better in Safari 7?

  • Ulrich says:

    It seems that the step attribute is ignored when using input datetime-local in safari on mobile devices. Does anyone know of a workaround?

  • Budiman says:

    Hello, Dr. Richard Clark I want to ask you about input type password, but show the numeric keyboard on android


  • Senthil kumar says:

    i want use tag .. but it appear only in chrome browser.. what shall i do for render this control in all browser….
    please give any idea abt this……. if any attribute i want to add this tag means , tell that attribute name……..

  • Anu says:

    thanks! how do i get the value from and store in the table? (using jquery or javascript)

  • Anu says:

    * input type=month

  • shikhar says:

    Hi all,

    I have been tried the input type as ‘time‘ but it did’t work in my case. Please help and elaborate to finalize the tag for more.

    Thanks in advance.


  • manish says:

    Input type ‘time’ is not working

  • @shikhar @manish – which browser(s) are you using? type=time isn’t implemented in all browsers at the moment see caniuse for more.

  • Tamara F says:

    Hi! I’m a student & I’m trying to associate text w/an inputtype=”number” form control (in my assignment, I have an input type =”number” & a label w/a price per item & when they select a higher number that there will be text underneath that says the total price… So, on 1, there’s no text and just a label of $1.00 that remains static but when they select 2, it says “($2.00 total)” underneath the $1.00 … Is there a way to do this? I’ve been searching the internet & can’t find anything and don’t know what it’d be called… Or, do I need to write a JavaScript function to do this for me?
    Anyways, I’ve come across your site looking for help/instruction online & thought maybe I’d ask if anyone knows…
    Thanks! Any help or explanation of what I need to do (or just what it’s Called so I can research it myself) would be much appreciated!

  • Join the discussion.

    Some HTML is ok

    You can use these tags:
    <a href="" title="">
    <abbr title="">
    <blockquote cite="">
    <del datetime="">
    <q cite="">

    You can also use <code>, and remember to use &lt; and &gt; for brackets.