HTML: HTML5 Form Validation Examples

The option of using pure HTML, sometimes with a touch of CSS, to
complement JavaScript form
validation was until recently unthinkable. Sure there have been all
kinds of whacky plug-ins over the years aimed at achieving this, but
never a single standard that we could work towards.

For a more detailed introduction to HTML5 form validation you can
find some great articles linked under References
below. In this article we intend to present only a number of simple
examples to get you started, covering the basic form elements.

Before you ask, and someone always does, these examples will
currently work in the following browsers: Safari 5, Chrome 6, Opera 9,
Firefox 4 Beta and the iPhone/iPad. Also each browser has a slightly
different default behaviour.

The 'required' attribute

The simplest change you can make to your forms is to mark a text
input field as 'required':

Your Name: <input type="text" name="name" required>

Your Name:

This informs the (HTML5-aware) web browser that the field is to be
considered mandatory. Different browsers may mark the input box in
some way (Firefox 4 Beta adds a red box-shadow by default), display a
warning (Opera) or even prevent the form from being submitted if this
field has no value. Hopefully these behaviours will converge in
future releases.

For these examples we have created our own valid/invalid CSS
formatting to override the browser default. More on
that later. That's why you may see something like the following:

Before you type anything into the box a red marker is shown. As
soon as a single character has been entered this changes to a green
marker to indicate that the input is 'valid'.

Using CSS you can place markers inside or alongside the input box,
or simply use background colours and borders as some browsers do by
default.

New text INPUT types

This is where HTML5 really gets interesting and more useful. Along
with the text input type, there are now a host of other
options, including email, url, number,
tel, date and many others.

On the iPhone/iPad the different input types are associated with
different keyboards, making it easier for people to complete your
online forms. In other web browsers they can be used in combination
with the required attribute to limit or give advice on
allowable input values.

INPUT type="email"

By changing the input type to email while also using the
required attribute, the browser can be used to validate (in a
limited fashion) email addresses:

Note that for this example we've made use of another HTML5
attribute placeholder which lets us display a prompt or
instructions inside the field - something that previously had to be
implemented using messy onfocus and onblur JavaScript
events.

The above code displays an input box as follows:

Email Address:

Again, different browsers implement this differently. In Opera it's
sufficient to enter just *@* for the input to be accepted. In
Safari, Chrome and Firefox you need to enter at least *@-.-.
Obviously neither example is very limiting, but it will prevent people
from entering completely wrong values, such as phone number, strings
with multiple '@'s or spaces.

Here is how it appears in Safari (with our CSS formatting to show the
(in)valid state):

INPUT type="url"

In a similar fashion to the email input type above, this
one is designed to accept only properly-formatted URLs. Of course it
currently does nothing of the kind, but later you will see how to
improve it's behaviour using the pattern attribute.

Website: <input type="url" name="website" required>

Again, the input box appears as normal:

Website:

This time the minimum requirement for most browsers is one or more
letters followed by a colon. Again, not very helpful, but it will stop
people trying to input their email address or other such nonsense.

As mentioned above, we can improve on this by making use of the
pattern attribute which accepts a JavaScript regular
expression. So the code above becomes:

Now our input box will only accept text starting with http:// or https:// and at least one additional character:

Website: starting with http

If you're not yet familiar with regular expressions, you really
should make it a priority to learn. For those already
familiar, note that the ^ and $ are already implicit
so the input has to match the entire expression. Pattern modifiers are not supported.

If anyone wants to contribute a more thorough expression to test
for valid email or url format, feel free to post it using the Feedback form.

INPUT type="number" and type="range"

The number and range input types also accept
parameters for min, max and step. In most
cases you can leave out step as it defaults to 1.

Here you see an example including both a number input,
typically displayed as a 'roller' and a range input displayed
as a 'slider':

As with other HTML5 input types, browsers that don't recognise the
new options will default to simple text inputs. For that reason it's a
good idea to include a size for the input box.

AgeSatisfaction(1-5)

The slider option is a bit bizarre in that no values are
displayed, but may be useful for more 'analog' inputs. There are some
bugs with the number input in that if you don't set a
max value, clicking 'down' with the input blank will result in
a very large number.

Here is how the two inputs are displayed in Safari:

and in Opera:

They are currently not supported in Firefox 4 Beta.

If you want to restrict the input of a text field to numbers without
having the up/down arrows associated with the input box, you can always
just set the input type to text and use a pattern of
"\d+" (one or more numbers).

Other HTML5 INPUT types

The search input will, in some browsers, change the styles
to match the browser or operating system default search field format.
You can see this demonstrated in the Search input above.

The tel input type is handy for the iPhone as it selects a
different input keyboard. There is no pattern-matching set by default
so you would have to implement that yourself using the
pattern attribute to accept only certain characters.

The color input is meant to let you select a hex-code from
a colour wheel - or similar - but as yet doesn't appear to have been
implemented in the wild.

The other date- and time-related options do have
an effect at least in Opera, with pop-up calendars and other devices
appearing to assist with input. While it would be great to see
something like this in every browser, for now you probably need to
stick with the ubiquitous JavaScript plugins.

Styling valid/invalid inputs using CSS

While the code we're using is slightly more complicated, this should
get you started:

The first set of styles can be used to mark an input box as
'invalid', by adding an icon, colouring the text or borders or similar.
It will apply to inputs that are required but empty, or to
inputs that have a required format/pattern which hasn't yet been met.

The -moz-box-shadow style is there just to prevent Firefox
4 Beta from adding it's default red border.

For inputs that are both required and 'valid' you can use the following:

This solution is still more complicated than it needs to be as it
requires two extra images to be loaded. Fortunately, we can assume that
all browsers supporting HTML5 form validation techniques will also
support images being replaced in the CSS by 'Base64 encoded datasets'.

Using a service such as Spritebaker or other techniques, the above style
settings become:

The above code can now be copied directly to your CSS style sheet.
There's no need to copy any images and, especially if your style-sheets
are gzip-compressed, there will be next to no impact on load times. In
a few minutes you could have your whole website updated.

For the browser-impaired, this is how the required input field will
appear in Safari with either the image or the Data URI
backgrounds:

The same styling can be extended to textarea elements, but
won't work for checkboxes,
select elements, etc. For those you might want to place the
valid/invalid markers alongside the element or format the input
elements themselves using borders, background colours, etc.

Fallback for the placeholder attribute

The following JavaScript, placed or included at the end of the page,
should enable support for the placeholder attribute in INPUT
fields at least for Internet Explorer 8+, Firefox and Opera:

User Comments

Great post. Been looking for some HTML5 validation techniques and this really helped.

Conor30 April, 2014

Great article, thanks!

Anyone out there know how to adjust the url validation so that it will accept inputs in the following format: www.website.com ? i.e. no need to force a user to input http:// or https://

You can find a comparison of some interesting regexes for validating URLs here. You just need to pick one and then remove the portion that detects the protocol (xxx://). But as you see, lots of strange looking URLs are actually valid.

Bongani Macheke8 November, 2013

I used

/^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}$/

to verify email addresses and it works!

As others have pointed out, this excludes some valid addresses - usernames including an apostrophe for example. Also some TLDs are longer than four characters.

I tested the email validation on both Safari and Chrome. It's not working correctly. Typing 'nobody@no' should not pass the validation but it did.

Most browsers accept xxx@yyy as valid for email input as it can be technically correct in some situations - on an intranet for example. If you want something more restrictive you can add a 'pattern' attribute. e.g pattern="[^ @]+@[^ @]+.[a-z]+"

Arjen30 May, 2013

Matthew Cunliffe & Mike, your email regexes are flawed. I have a vaild address with a plus sign (+) in it which will be rejected by your regex (and, as I experience, by many many websites).

Carl27 March, 2013

Thanks for an interesting post.
Q. How do you only show the fields as 'invalid' after the user leaves (blurs?) the field (or after they've hit send). It's ugly to have ready icons displayed when the page loads. thx

Daniel5 February, 2013

I can't get the form validation working in Safari 6.0.1. I can't submit the form but I get no error message. It works here with your red/green symbols though. Any suggestions?

Safari doesn't display any HTML5 validation messages, but it may prevent the form from submitting if any "required" fields are left blank. The messages will appear in Firefox and Opera.

The red/green symbols are applied using CSS and do work in Safari, but are only an indication of whether the input for that field is valid.

You forgot the most important part: by having these standard types to identify the fields, browsers can provide helpful autofill interfaces. When you select a “tel” or “email” field on your mobile browser, it could open your address book for you to pick a phone number or address from.

The fallback for the placeholder attribute in this article is far from accurate. The main problem is that if the user doesn't enter a new value, the placeholder text will be submitted along with the form. I would highly recommend using one the various placeholder polyfill scripts if you want to support the placeholder attribute in older browsers: e.g. github.com/jamesallardice/Placeholders.js

Wish there were some demos of the tel type and others to test them out.

The "tel" type seems to only affect the input keyboard for iOS and perhaps similar devices. The "date" input AFAIK has only been implemented in Opera, but hopefully some day there will be cross-browser support for all the new types.

mivpljiapur14 July, 2012

you can place markers inside or alongside the input box, or simply use background colours and borders as some browsers do by default.

If you're relying strictly on client-side validation for form validation, you're doing it completely wrong. Personally, HTML5 form validation is just as reliable as client-side validation using JavaScript.

JeramieH12 October, 2011

It's probably obvious but worth being repeated: never trust the client. Yes, this will be great for 99% of the cases, but hackers will intentionally submit data via manual tools just to mess with your system. So always validate on the server as well, just to be certain.