Use forms to allow users to enter data, submit inquiries, change settings, find information, or generally complete other tasks. When designing forms, aim to collect as little information as possible through a limited number of steps.
Use single-column forms wherever possible. Multi-column forms may lead to confusion and can result in users skipping fields and inputting data in the wrong field. In some scenarios, it’s OK to include more than one field in a row, but this should only be done when the data requested by each field are related or understood by the user to be part of the same set. Examples where this is acceptable include ‘city + province + postal code’ and ‘credit card number + expiry + CVV’. If you aren’t sure, always default to a new line for each form field.
Do: Default to a single column layout
Don't: Use a multi-column layout
Field widths should always match the length of the expected input and should rarely exceed 400px.
Do: Ensure field length matches data length
Don't: Use fields that are too long for the expected data
Use the title to describe the form. If the form is the main item on a page, use an
h1, otherwise, use
h3 and adjust the rest of the page hierarchy accordingly. Where possible, follow the form title with a brief description.
Use fieldset and labels (
legend tags) to group and describe a set of controls and/or fields within a form. These should be grouped to help users understand what is required of them in a logical way. Try to make the headline concise and informative, but where needed, you can add a short paragraph of text to explain the group.
For an example of fieldsets in use see our name and address form example.
Labels should be written in sentence case and always indicate what sort of information the input requires.
Helper text gives context about an input. It’s best to provide an example here, rather than as placeholder text so that it’s visible after the text has been entered (specific to text fields). Only use helper text where clarification is required, and try not to overuse it. Standard helper text alignment is close beneath the form input.
Error messages display instructions on how to correct data that hasn’t been accepted. Error messages are displayed below the input line, replacing helper text until fixed. Wherever possible, consider using dynamic validation that detects errors and provides feedback as data is entered.
Validation icons help indicate what state the field has. This includes feedback (warning, error, success, etc) or utility (more info, show/hide password, clear).
Dropdown icons indicate that a selection should be made from a larger list within a select dropdown.
Required and optional inputs
Wherever possible, only include form inputs that are absolutely necessary; ‘shorter is better’ should be the approach when it comes to form design. If you decide to add optional inputs, these fields should be marked with ‘Optional’ in parentheses above and to the right of the label. Labelling required form inputs with an asterisk is not recommended as this pattern isn’t as obvious or accessible as including ‘(Optional)’ along with the input label.
Do: Add an ‘optional’ label to optional fields
Don't: Add an asterisk or otherwise mark required fields
Breaking large forms into multiple steps reduces friction (both real and perceived), creates a manageable first impression, and provides an opportunity to show progress.
Try and limit the number of inputs per step with 5 +/- 2 as your guide. Each step should have a theme that’s easy to identify and understand.
When using buttons to help a user move through a series of stepped screens, right-align the primary button to visually support the intended direction.
Bootstrap’s form controls expand on Rebooted form styles with classes. Use these classes to opt into their customized displays for a more consistent rendering across browsers and devices.
Be sure to use an appropriate
type attribute on all inputs (e.g.,
number for numerical information) to take advantage of newer input controls like email verification, number selection, and more.
Since Bootstrap applies
display: block and
width: 100% to almost all our form controls, forms will by default stack vertically. Additional classes can be used to vary this layout on a per-form basis.
.form-group class is the easiest way to add some structure to forms. It provides a flexible class that encourages proper grouping of labels, controls, optional help text, and form validation messaging. By default it only applies
margin-bottom, but it picks up additional styles in
.form-inline as needed. Use it with
<div>s, or nearly any other element.
More complex forms can be built using our grid classes. Use these for form layouts that require multiple columns, varied widths, and additional alignment options.
You may also swap
.form-row, a variation of our standard grid row that overrides the default column gutters for tighter and more compact layouts.
As shown in the previous examples, our grid system allows you to place any number of
.cols within a
.form-row. They’ll split the available width equally between them. You may also pick a subset of your columns to take up more or less space, while the remaining
.cols equally split the rest, with specific column classes like
The example below uses a flexbox utility to vertically centre the contents and changes
.col-auto so that your columns only take up as much space as needed. Put another way, the column sizes itself based on the contents.
You can then remix that once again with size-specific column classes.
.form-inline class to display a series of labels, form controls, and buttons on a single horizontal row. Form controls within inline forms vary slightly from their default states.
- Controls are
display: flex, collapsing any HTML white space and allowing you to provide alignment control with spacing and flexbox utilities.
- Controls and input groups receive
width: autoto override the Bootstrap default
- Controls only appear inline in viewports that are at least 576px wide to account for narrow viewports on mobile devices.
You may need to manually address the width and alignment of individual form controls with spacing utilities (as shown below). Lastly, be sure to always include a
<label> with each form control, even if you need to hide it from non-screenreader visitors with
Alternatives to hidden labels
Assistive technologies such as screen readers will have trouble with your forms if you don’t include a label for every input. For these inline forms, you can hide the labels using the
.sr-only class. There are further alternative methods of providing a label for assistive technologies, such as the
title attribute. If none of these are present, assistive technologies may resort to using the
placeholder attribute, if present, but note that use of
placeholder as a replacement for other labelling methods is not advised.
Helper text gives context about an input. It’s best to provide an example here, rather than as placeholder text so that it’s visible after the text has been entered (specific to text fields). Only use helper text where clarification is required, and try not to overuse it.
Block-level help text in forms can be created using
.form-text (previously known as
.help-block in v3). Inline help text can be flexibly implemented using any inline HTML element and utility classes like
Associating help text with form controls
Help text should be explicitly associated with the form control it relates to using the
aria-describedby attribute. This will ensure that assistive technologies—such as screen readers—will announce this help text when the user focuses or enters the control.
Help text below inputs can be styled with
.form-text. This class includes
display: block and adds some top margin for easy spacing from the inputs above.
Inline text can use any typical inline HTML element (be it a
<span>, or something else) with nothing more than a utility class.
disabled boolean attribute on an
<fieldset> to prevent user interactions and make it appear lighter.
Caveat with anchors
By default, browsers will treat all native form controls (
<button> elements) inside a
<fieldset disabled> as disabled, preventing both keyboard and mouse interactions on them. However, if your form also includes
<a ... class="btn btn-*"> elements, these will only be given a style of
While Bootstrap will apply these styles in all browsers, Internet Explorer 11 and below don’t fully support the
disabled attribute on a