A Guide to the New HTML5 Form Input Types

A Guide to the New HTML5 Form Input Types

There’s a plethora of new HTML5 form input types (13 new ones to be exact) that make creating engaging and easy-to-use web forms much easier for web designers. The new HTML5 input types give us data validation, date picker controls, color picker controls, inline help text, and more in the web browsers that support them.

Advantage of HTML5 Form Input Types

The benefits of these new input types are tremendous for web designers.

First, the new input types reduce our reliance on client-side- and server-side-scripting for validating common data types like dates, email addresses, and URLs.

For mobile UI developers: You know that creating cross-platform web forms using HTML4 standards is a pain. Using HTML5 form input types could make things easier.

For instance, a form written with HTML5 can utilize the mobile device’s native specialized keyboards depending on what the target input type is.

Here’s an example of using HTML4 input types (on the left) for entering dates in a web form versus using the HTML5 date input type (on the right):

The difference between using HTML4 versus the HTML5 date input type.

Notice how the iPhone’s native keyboard automatically switches over to its native date picker control because it knows that the target input is a date.

Here are other examples.

url Input Type

email Input Type

The New HTML5 Form Input Types

Here’s a table of all the new HTML5 input types for your reference.

Input Type Description HTML Markup
date A control for entering the date. <input type="date">
datetime Date and time using UTC date and time format <input type="datetime">
datetime-local Date and time according to your local time <input type="datetime-local">
month Month and year <input type="month">
time The time of day <input type="time">
week Allows you to pick the week and year. <input type="week">
color Allows you to enter a simple color value (which is in hexadecimal color notation) <input type="color"">
email Validates the input using the standard email format <input type="email">
tel Gives you the ability to validate telephone numbers format against a pattern <input type="tel">
search Searches a data set (like a <datalist> HTML element) <input type="search">
range A slider control for picking a number in between two numbers <input type="range">
number Accepts numbers only <input type="number">
url Accepts URLs only <input type="url">

HTML5 Form Input Types Demo

Here’s a live demo of each input type so that you can play around with them.

Note: This demo page will only work on browsers that support these input types, so it might not work properly when you view it.

We also recommend viewing this demo page on different browsers so you can see how each browser treats these input types; they differ drastically in some cases.

Let’s talk about the new input types.



The calendar date picker is a standard UI design pattern for allowing users to enter date information in web forms. This is useful for asking users to enter their date of birth or credit card expiration date.

This UI pattern is so common that in HTML5, there’s now the date input type that makes it dead-simple to include date pickers in your web forms. No more JavaScript or server-side programming or installing jQuery plugins, you just need HTML markup (and CSS to make it look prettier).



This input type is designed to take in a global date and time string.



This input type is for a local date and time string.



If you want to allow users to enter a month, this is the input type to use.



If you want to allow users to enter a week (such as the 31st week of 2013) this is the input type to use.



This is for inputting the time in the the day. Some browsers will use military time by default (e.g. 16:00), while others use the AM/PM format (e.g. 4:00PM).



The color picker UI design pattern is a way of allowing users to choose a color. The color input type gives you a form input control for a picking hexadecimal color value.

Some browsers (like Safari) won’t show you a color picker UI though, they’ll just check whether or not the data is a hexadecimal color code (e.g. #000000).



In HTML5-compatible browsers, this input type is set to validate the entered data for the correct email address syntax.



This input type is ideal for taking in phone numbers.



The search input type is meant to be used with a data set such as the datalist HTML element or the results of querying a MySQL database. It searches the data set for a match, and also gives you a list of suggestions as you type (which is called the autocomplete user interface pattern).



This input type is another way to get number-related data from users. By default, it has a slider user interface.



This input type restricts data entries only to numerical values. If you include min and max attributes, it also validates the data input to make sure the number is between the min/max values.



Theis input type validates the entered data to make sure that it follows the standard URL format.


These additional input types in HTML5 help us build user-centered web forms easier. The modern web designer no longer needs to break his/her back in order to enable more complex data input patterns.

The times are changing for all of us. Let’s not forget to update our forms to match.

Related Content

About the Author

Yigit Kocak is an online web form specialist at JotForm, a service dedicated to help people create, manage, and share online forms.

This was published on Jun 7, 2013


Mattias Jun 07 2013

What happens when a non-HTML5 compatible browser renders an input field with a HTML specific type, like type=”email”?

Will it fall back to the default type which is text?

byroot Jun 07 2013

@Mattias: exacly.

But the real issue is more browser with partial / broken support of these new types.

Napolux Jun 07 2013

It will fall back to text.

eblin Jun 07 2013

@Mattias, Yes it will fallback to text.

@Mattias, Yes. It reverts back to a text field.

Simon Fredsted Jun 07 2013

Yep, it falls back to a standard textfield. Good idea to add some JavaScript to make sure the formatting is OK in case the fields aren’t supported.
Also, ironically the fields on this page aren’t using the new HTML5 input types :-)

Yigit Jun 07 2013

That’s correct.

If the browser doesn’t support it, it will behave as regular text fields.

Prateek Jun 07 2013

Yes it will :)

Paul Irish Jun 07 2013

@Mattias, Yup, that’s exactly what happens. :) works great.

“First, the new input types reduce our reliance on client-side- and server-side-scripting for validating common data types like dates, email addresses, and URLs.”

Please don’t say that. Whatever you do on the client, malicious users can still send hand-crafted HTTP requests to your server. Make sure to handle bad input gracefully. Never trust the client to use your client-side validation. It can only augment server-side validation.

Basti Jun 07 2013

Yes it will fall back to input type text

Daniel Jun 07 2013

According to W3Schools it will act as a standard text field if it is a non-HTML5 compatible browser.

ghosttie Jun 07 2013

I look forward to using this in about fifteen years when all browsers support it

sunny Jun 07 2013

Yes, it will work as text input type for older browsers.

Yeah, Firefox displays plain old text boxes – making it impossible to figure out the proper formatting to submit.

TheSisb Jun 07 2013

@Mattias, yes it does.

Rishi Jun 07 2013

What I liked about the HTML5 inputs is that it follows the stock way of implementing the boxes, like if you use an iPhone, it will show up the same UI for dropdowns, inputs, dates etc and same with Android.

peter Jun 08 2013

Unfortunately browsers like IE will not be able to handle it.

Jacob Gube Jun 08 2013

@Leif: You wouldn’t just use client-side validation on critical data that you’re going to be writing into your database.

It’s simply for reducing the load and need of having to validate simple user errors, like a typo in email address format (e.g., typing and accidentally forgetting the @). You validate for these simple errors before they need to take a trip to the server or your client-side script. After the data is in the correct format, that’s when you send it to the server for validation, sanitation, and writing into the database.

Imagine this scenario: I enter the wrong email format such as That obviously wrong data gets sent to the server, the server processes that data and tells me, “Hey, your email address is wrong”.

Now imagine this alternative: Let the browser deal with those simple errors.

When the data passes browser validation (or the user exploits/works around our browser-based validation), that’s when you send it to the server (or script) to re-validate and sanitize.

That last scenario is better for me, the user (because I don’t have to wait for the server to respond to tell me that I made a simple typing error) and it’s good for the site owner because it reduces the burden on her servers from validating honest typos, which contributes (in a relatively small degree) to the overall improvement of web performance on her website.

How about using JavaScript for these simple typos? That’s the current solution. But wouldn’t it be awesome if I didn’t have to though? Wouldn’t it be cool If I can just tell the browser through my markup, “Hey this input field is an email address, please treat it as such. You’re very smart, I think you can handle that pretty simple task for most of the people that use you. Thanks, now I can focus on the more complex stuff.”

Jacob Gube Jun 08 2013

Just a quick question to you all: Should that statement that @Leif quoted be revised for (even more) clarity?

This statement is what I’m referring to: “First, the new input types reduce our reliance on client-side- and server-side-scripting for validating common data types like dates, email addresses, and URLs”.)

I don’t think it suggests to eliminate server-side validation/sanitation. But does that statement give off that message?

Personally, I take it as saying that it reduces the reliance on validating user inputs for common typing errors before even sending it to the server.

Because common knowledge to me would be to validate/sanitize ALL user data going into the server that has the potential of being harmful, because I can’t guarantee that all users will be using browsers that will have these HTML5 validation features, and I also know that browsers, even if they do support these input types, treat them differently, and also because I know that I can manipulate my browser to not validate my inputs if I really wanted to.

Your thoughts appreciated!

As I suppose my comment suggests I really did read the paragraph as if you were suggesting to do less validation on the server. It obviously *can* be understood to mean that by at least some. In my opinion, that’s reason enough to reword it.

(You cannot rely on common knowledge when posting things on the Internet — I’m especially concerned about younger developers just getting started; imagine your blog post is part of the “common knowledge” they are currently forming for the rest of their careers.)

arnold Jun 08 2013

yep I do agree with you

it can reduce client-side scripting , because of the new types and new attributes which wasnt mention in the article,

Here is an info about the attributes:

If your website will support other browsers who isnt ready for html5 , there are pollyfill for that so it could fallback for a javascript support ,

Here is an info

About the server scripting , I would say yes it will still be needed, thats a rule folks.
Never trust users

Yetsi Jun 08 2013

I tried this with Microsoft Internet explorer 7 and it didn’t work properly. What I am doing wrong?

Jacob Gube Jun 09 2013

@Leif: Yes, that’s my concern too, that’s why I asked. If there’s even 1 person that could interpret that statement to say that “yay, these input types mean I don’t need to use server-side scripting to validate user inputs anymore,” that means it should be updated. I’ll update it to reduce ambiguity.

Mathew Porter Jun 13 2013

Some of the input types are going to be amazing for systems and forms, just a shame support isnt entirely there yet to use on projects, although this is the case with most of html5 and css3 markup. In addition to your post here is a nice article listing support for input elements:

Šime Vidas Jun 14 2013

Damn. Support sucks in Firefox :-(

EZ Design Team Jun 16 2013

Those that are saying that they can not get the forms to show on specific browsers, check out You can get a score for your browser with plug-ins and operating system.

I have tested and posted but did find that Google Chrome on Windows 8 was the best out of the 5 browsers I have installed on my computer. I have 5 because of the designs I already do and like to test cross browsers. Here are my results with no plug-ins:

Safari 5.1.7 on Windows 8 scores 278+2 bonus points out of 500
Chrome 27 on Windows 8 scores 463+13 bonus points out of 500
Internet Explorer 10 on Windows 8 scores 320+6 bonus points out of 500
Firefox 21 on Windows 8 scores 399+14 bonus points out of 500
Opera 12.15 on Windows 8 scores 404+9 bonus points out of 500

Finding from

This comment section is closed. Please contact us if you have important new information about this post.