Poorly communicated errors can be frustrating for users. Apply the following guidelines when handling errors:
Write error messages in clear and simple language. User should be able to understand the problem while reading an error message.
Include suggestions on how to resolve the error.
Avoid technical jargon.
Don’t use negative words and never blame the user.
Use a general error message to communicate that something went wrong but also ensure specific messages are used inline and placed where the error took place.
Try to prevent errors from occurring in the first place. For example; if a date in the future is required, disable the ability to select a date in the past. If errors do occur let the user know right away. Make sure it’s clear what the error is, and where it occurred. If possible, implement inline validation with real-time feedback right after the answered question. This will increase success rates and satisfaction, and decrease errors made and completion time.
Symbolic colours (such as red for error) and icons are often used to help signify meaning to a user for error messages, warnings and success messages. Never rely solely on colours or icons, they should be used along with supporting text so that the information is accessible for all users.
Please provide a valid email address.
Do: Use specific messages where the error took place
Please provide a valid email address.
Don't: Rely solely on colours and/or icons to communicate errors
How it works
Provide valuable, actionable feedback to your users with HTML5 form validation–available in all our supported browsers. Choose from the browser default validation feedback, or implement custom messages with our built-in classes and starter JavaScript.
We currently recommend using custom validation styles, as native browser default validation messages are not consistently exposed to assistive technologies in all browsers (most notably, Chrome on desktop and mobile).
Here’s how form validation works with Bootstrap:
HTML form validation is applied via CSS’s two pseudo-classes, :invalid and :valid. It applies to <input>, <select>, and <textarea> elements.
Bootstrap scopes the :invalid and :valid styles to parent .was-validated class, usually applied to the <form>. Otherwise, any required field without a value shows up as invalid on page load. This way, you may choose when to activate them (typically after form submission is attempted).
To reset the appearance of the form (for instance, in the case of dynamic form submissions using AJAX), remove the .was-validated class from the <form> again after submission.
As a fallback, .is-invalid and .is-valid classes may be used instead of the pseudo-classes for server side validation. They do not require a .was-validated parent class.
Due to constraints in how CSS works, we cannot (at present) apply styles to a <label> that comes before a form control in the DOM without the help of custom JavaScript.
All modern browsers support the constraint validation API, a series of JavaScript methods for validating form controls.
Feedback messages may utilize the browser defaults (different for each browser, and unstylable via CSS) or our custom feedback styles with additional HTML and CSS.
You may provide custom validity messages with setCustomValidity in JavaScript.
With that in mind, consider the following demos for our custom form validation styles, optional server side classes, and browser defaults.
Custom styles
For custom Bootstrap form validation messages, you’ll need to add the novalidate boolean attribute to your <form>. This disables the browser default feedback tooltips, but still provides access to the form validation APIs in JavaScript. Try to submit the form below; our JavaScript will intercept the submit button and relay feedback to you. When attempting to submit, you’ll see the :invalid and :valid styles applied to your form controls.
Custom feedback styles apply custom colours, borders, focus styles, and background icons to better communicate feedback. Background icons for <select>s are only available with .custom-select, and not .form-control.
Browser defaults
Not interested in custom validation feedback messages or writing JavaScript to change form behaviours? All good, you can use the browser defaults. Try submitting the form below. Depending on your browser and OS, you’ll see a slightly different style of feedback.
While these feedback styles cannot be styled with CSS, you can still customize the feedback text through JavaScript.
Server side
We recommend using client-side validation, but in case you require server-side validation, you can indicate invalid and valid form fields with .is-invalid and .is-valid. Note that .invalid-feedback is also supported with these classes.
Validation classes .is-invalid and .is-valid can be toggled with JQuery when there is a change to a field, and when the form is submitted.
Required fields will use the togglevalid() function below to ensure the appropriate class is defined in the field.
Optional fields which allow any format will not require JQuery to toggle classes, since these fields are always valid.
Optional fields which require a defined format when they are entered, for example an optional phone number field, will use the toggleavalidoptional() function.
For example, you may have a form with three fields:
Name (optional) - any text allowed
Phone Number (optional) - if entered must be in format 000-000-0000
Email Address - this is a required field
Supported elements
Validation styles are available for the following included form controls and components:
<input>s and <textarea>s with .form-control (including up to one .form-control in input groups)
<select>s with .custom-select
.custom-checkboxs and .custom-radios
Customizing
Validation states can be customized via Sass with the $form-validation-states map. Located in our _variables.scss file, this Sass map is looped over to generate the default valid/invalid validation states. Included is a nested map for customizing each state’s colour and icon. While no other states are supported by browsers, those using custom styles can easily add more complex form feedback.
Please note that we do not recommend customizing these values without also modifying the form-validation-state mixin.