The current state of <input type=“email“ />

One of the best-known new features of HTML5 are semantic form input fields. Until now, you had the choice between text input fields, radio- and checkboxes, dropdowns and textareas. That was pretty much it. HTML5 extends this by adding new input fields for specific requirements, like entering a date, email or URL.

So the typical
<input type=“text“ name=“user_mail“ />
turns into
<input type=“email“ name=“user_email“ />

Check out our mini example form.

Why using the new input types?

Letting a browser know the purpose of an input field might make him offer specific input helpers. For example, entering dates often comes together with website-specific date-picker widgets. Date, email and URL input fields are often validated using Javascript. This way, typos and invalid input are already filtered out on the client-side. Until now, these tasks had to be coded by a web developer. With HTML5, the browser supports them natively. So there are advantages for all stakeholders involved:

  1. Web developers: Less work.
    No need to add code for validation / helpers (date-picker, …).
  2. Web users: Consistency.
    Same validation and helpers on ALL web pages.

Current state: Mobile browsers

iPhone: <input type="text" />

If you take a look at the mini form example using the iPhone Safari browser, you will find out that it does not validate the fields. But it does something else, which is quite cool: When filling a normal text input field, the iPhone shows the regular touch keyboard. For email and URL input fields, it displays the according special keyboards, which only contain allowed characters for the given fields.

iPhone: <input type="email" />

Normally, the @ sign is hidden in the alternative keyboard. So entering the @ requires three different clicks („switch keyboard“, „@“, „switch keyboard“). The specific email input keyboard shows all valid characters on one keyboard, including the @ sign.

iPhone: <input type="url" />

Same for the URL input keyboard: It contains almost all necessary URL characters on one view and also has the „.com“ shortcut at the bottom.

These days, entering data on mobile devices is still a bit of a pain. Even better, when such great user experience features can be used to take a bit of the pain away!

Current state: Desktop browsers

Good news first: In case an outdated browser does not understand the new HTML5 input types „email“ and „url“, it will handle these as regular „text“ fields. Modern web browsers (Chrome, Safari, FF6+, IE9+) are aware of the new field types and offer client-side validation. Let’s take a look at the browser with the biggest market share, Firefox 7.0.

In case you enter text into an „email“ / „URL“ field and the input is considered to be invalid, Firefox adds a red border to the field. When you try to submit the form, it won’t let you and present a message stating „Please enter a valid email-address/URL“.

Some validation examples for input type email:

  • foo => invalid
  • foo@ => invalid
  • foo@bar => valid
  • foo@bar. => invalid
  • foo@bar.b => valid
  • => valid
  • fooä => invalid
  • foo@barä.boo => invalid

As you might see: Firefox only validates the syntax, not whether the domain oder country code really exists. Very important for non-english users: Firefox currently threats an email containing special characters like German umlauts as invalid, although these are perfectly valid. This is an internal Firefox bug, which is still pending.

Some validation examples for input type url:

  • foo => invalid
  • http => valid
  • http:// => valid
  • http://foo => valid
  • => valid
  • http://foo?ä.com => valid

URL-Validation seems to be not really implemented right now: Just entering „http“ is enough for being valid. Messing up domain names with special characters or entering invalid domains is not recognized to be invalid.


Given the current browser support in late 2011, you cannot use the new HTML5 input fields „url“ and „email“ to let the browser reliably validate user input. You also have to be careful with international email addresses, as Firefox might even block valid addresses in case they contain umlauts & co.

A great benefit is already implemented on mobile touch devices like the iPhone. Depending on the input field type, users will receive exactly the right touch keyboard for filling the input field.