Ask users for Email addresses

This guidance is for government teams that build online services. To find information and services for the public, go to GOV.UK.

WCAG 2.2

New WCAG 2.2 criteria affects this pattern

To ask users for ‘Email addresses’ and meet the new Web Content Accessibility Guidelines (WCAG) 2.2 criteria, make sure that users can successfully:

See the full list of components and patterns affected by WCAG 2.2.

This guidance is for government teams that build online services. To find information and services for the public, go to GOV.UK.

<div class="govuk-form-group">
  <label class="govuk-label" for="email">
    Email address
  </label>
  <div id="email-hint" class="govuk-hint">
    We’ll only use this to send you a receipt
  </div>
  <input class="govuk-input" id="email" name="email" type="email" spellcheck="false" aria-describedby="email-hint" autocomplete="email">
</div>
{% from "govuk/components/input/macro.njk" import govukInput %}

{{ govukInput({
  label: {
    text: "Email address"
  },
  hint: {
    text: "We’ll only use this to send you a receipt"
  },
  id: "email",
  name: "email",
  type: "email",
  autocomplete: "email",
  spellcheck: false
}) }}

When to use this pattern

Follow this pattern whenever you need to capture an email address.

How it works

When asking users for their email address, you must:

  • make it clear why you’re asking
  • make sure the field works for all of your users
  • help users to enter a valid email address

You may also need to check that users have access to the email account they give you.

<div class="govuk-form-group">
  <label class="govuk-label" for="email">
    Email address
  </label>
  <div id="email-hint" class="govuk-hint">
    We’ll only use this to send you a receipt
  </div>
  <input class="govuk-input" id="email" name="email" type="email" spellcheck="false" aria-describedby="email-hint" autocomplete="email">
</div>
{% from "govuk/components/input/macro.njk" import govukInput %}

{{ govukInput({
  label: {
    text: "Email address"
  },
  hint: {
    text: "We’ll only use this to send you a receipt"
  },
  id: "email",
  name: "email",
  type: "email",
  autocomplete: "email",
  spellcheck: false
}) }}

Reusing entered email addresses

WCAG 2.2

Make sure users can easily reuse a previously entered email address within a single journey, unless doing so would be a major safety or security concern. This is to comply with WCAG 2.2 success criterion 3.3.7 Redundant Entry.

You can make it easier to reuse email addresses through one of these methods:

  • pre-populate the email field with the previously entered email address
  • show any previously entered email addresses as an option for the user to select

Continue to give users the option to enter a new email address.

Tell users why you want the email address

Make it clear what the email address will be used for so that:

  • users feel confident that you’re not going to abuse it
  • users with multiple email addresses can choose which one to give you

If the email address field is part of a sign-in box, you do not need to say ‘We need your email so we can sign you in’.

Make sure the field works for all of your users

Make sure the field can accommodate up to 254 characters, which is the longest an email address can be.

Help users to enter a valid email address

Help your users to enter a valid email address by:

  • checking they have entered the correct format
  • allowing users to paste the email address
  • setting the type attribute to email so that devices display the correct keyboard
  • setting the spellcheck attribute to false so that browsers do not spellcheck the email address
  • confirming their address back to them so they can check and change it

You should also set the autocomplete attribute to email. This lets browsers autofill the email address on a user’s behalf if they’ve entered it previously.

If you are working in production you’ll need to do this to meet WCAG 2.1 Level AA. You will not normally need to use the autocomplete attribute in prototypes, as users will not generally be using their own devices.

The field should be wide enough for most users to see their entire email address once they have entered it. A good rule of thumb is to make sure you can see at least 30 characters at once. You can analyse your user data to refine this.

You can check for common misspellings of popular email providers, for example ‘homtail.com’ instead of ‘hotmail.com’. Warn users if you detect one, but allow them to proceed in case it’s a genuine email address.

Some services ask users to repeat their email address. Only do this if your user research shows it to be effective.

Check the user has access to their email account

If email is an essential part of your service - for example to send a password reset - you can confirm whether the user has access to the email address they give you using an email confirmation loop.

However, these are disruptive and should be avoided as far as possible.

Error messages

Error messages should be styled like this:

<div class="govuk-form-group govuk-form-group--error">
  <label class="govuk-label" for="email">
    Email address
  </label>
  <div id="email-hint" class="govuk-hint">
    We’ll only use this to send you a receipt
  </div>
  <p id="email-error" class="govuk-error-message">
    <span class="govuk-visually-hidden">Error:</span> Enter an email address in the correct format, like name@example.com
  </p>
  <input class="govuk-input govuk-input--error" id="email" name="email" type="email" spellcheck="false" value="Not an email address" aria-describedby="email-hint email-error" autocomplete="email">
</div>
{% from "govuk/components/input/macro.njk" import govukInput %}

{{ govukInput({
  label: {
    text: "Email address"
  },
  hint: {
    text: "We’ll only use this to send you a receipt"
  },
  id: "email",
  name: "email",
  type: "email",
  value: "Not an email address",
  autocomplete: "email",
  errorMessage: {
    text: "Enter an email address in the correct format, like name@example.com"
  },
  spellcheck: false
}) }}

Make sure errors follow the guidance in error message and have specific error messages for specific error states.

If the email address is not in the correct format and there is no example

Say ‘Enter an email address in the correct format, like name@example.com’.

If the email address is not in the correct format and there is an example

Say ‘Enter an email address in the correct format’.

Help improve this pattern

To help make sure that this page is useful, relevant and up to date, you can:

Tell us if your service uses this pattern

Take part in our usage survey (opens in a new tab) to help us improve this pattern to better meet the needs of the services that use it.

Need help?

If you’ve got a question about the GOV.UK Design System, contact the team.