Skip to main content
Design system

Beta This is a new service. Your feedback will help us improve it.

Text input

Updated in October 2026

Use text input to let users enter a single line of text.

Open this example in a new tab

When to use text input

Use the text input component when you need users to enter text that's no longer than a single line, such as their name or phone number.

Asking 1 question per page is recommended for public-facing services. Breaking questions into smaller steps helps users:

  • understand what you're asking them to do
  • focus on the specific question and its answer

Sometimes it is more appropriate to group related questions on the same page. For example, users of clinical-facing services may need to view, compare or enter multiple pieces of information quickly.

Use research and evidence from your service to decide which approach works best for your users.

When not to use text input

Do not use this component if you need users to enter longer answers that might span several lines. In this case, use the textarea component.

How to use text input

Give the text input a label

Give it a visible label. Do not use placeholder text for a label as it vanishes when users click on the text input.

Align labels above the text inputs they refer to. Labels should be short, direct and written in sentence case. Do not use colons at the end of labels.

If you're asking 1 question on the page

Open this example in a new tab

You can set the contents of the <label> as the page heading if you're asking more than 1 question on a page. This is good practice as it means that screen reader users will only hear the contents once.

Read more about Making labels and legends headings on the GOV.UK Design System.

If you're asking more than 1 question on the page

Open this example in a new tab

Do not set the contents of the <label> as the page heading if you're asking more than 1 question on a page.

Read more about Asking multiple questions on question pages in the GOV.UK Design System.

Make text inputs the right size

Help users understand what they should enter by making text inputs the right size for the information you want them to give you.

By default, the width of text inputs is fluid and will fit the full width of the container they are placed into.

If you want to make the input smaller, you can either use a fixed width input, or use the width override classes to create a smaller, fluid width input.

Fixed width inputs

Open this example in a new tab

Use fixed width inputs for content that has a specific, known length. For example, postcode inputs should be postcode-sized and phone number inputs should be phone-number-sized.

On fixed width inputs, the width will remain fixed on all screens unless it is wider than the viewport, in which case it will shrink to fit.

Fluid width inputs

Open this example in a new tab

Use width override classes to reduce the width of an input in relation to its parent container, for example, to two-thirds.

Fluid width inputs will resize with the viewport.

Using hint text

Open this example in a new tab
Hint text goes here

You can use hint text to give users help in context, so they understand what they need to enter. For example, use it to tell users where to find information or how you will use their data. Read more about hint text.

Do not disable copy and paste

Users often need to copy and paste information into a text input, so do not stop them doing this.

Accessibility

When implemented in production, fields should identify their purpose so browsers and assistive technologies can support features such as autofill and reduce user effort. This is to support WCAG 2.2 Success Criterion 1.3.5 Identify Input Purpose, level AA.

Do not use placeholder text as a label for a text input. It disappears when users click inside the textarea and may not be announced consistently by assistive technologies. This supports WCAG 2.2 Success Criterion 3.3.2 Labels or Instructions, level A.

Associate labels programmatically with text inputs so assistive technologies can identify the purpose of each field. This supports WCAG 2.2 Success Criterion 1.3.1 Info and Relationships, level A.

Source

Learn more about Text input in the GOV.UK Design System.

Back to top

Text input variants

Asking for numbers

Whole numbers

Open this example in a new tab
Must be between 6 and 8 digits long

If you're asking the user to enter a whole number, set the inputmode attribute to numeric to use the numeric keypad on devices with on-screen keyboards.

Decimal numbers

Read more about Asking for decimal numbers in the GOV.UK Design System.

Prefixes and suffixes

Open this example in a new tab

Use prefixes and suffixes to help users enter things like currencies and measurements.

Prefixes and suffixes are useful when there's a commonly understood symbol or abbreviation for the type of information you're asking for.

Do not rely on prefixes or suffixes alone, because screen readers will not read them out. Screen readers may not announce them, so you should also explain the required format in the label or hint text. For example, use the label "Cost, in pounds" alongside a £ prefix.

Position prefixes and suffixes so that they're outside of their input. This is to avoid interfering with some browsers that might insert an icon into the input, for example to show or generate a password.

Some users may not notice a prefix or suffix and include it in their answer. Your validation should allow for this and should not show an error.

Back to top

Examples

Welsh Immunisation System (WIS)

This example is from the School-age Immunisations service within WIS. It shows a text input asking a parent or guardian for their full name as a single, focused question on the page.

Full name question with a single text input and Continue button

Back to top