VeeValidate Logo


Customize VeeValidate behaviors

Visit the rules documentation to learn more about how to use each rule and how to create your own.


You may need to configure some options to tweak some of the plugin internals. This is not required, but could cause conflicts. For example, using a property called errors on your vue instance may cause conflicts. Here is how you would set up the options, along with the default values:

import Vue from 'vue';
import VeeValidate from 'vee-validate';

const config = {
  errorBagName: 'errors', // change if property conflicts
  fieldsBagName: 'fields',
  delay: 0,
  locale: 'en',
  dictionary: null,
  strict: true,
  classes: false,
  classNames: {
    touched: 'touched', // the control has been blurred
    untouched: 'untouched', // the control hasn't been blurred
    valid: 'valid', // model is valid
    invalid: 'invalid', // model is invalid
    pristine: 'pristine', // control has not been interacted with
    dirty: 'dirty' // control has been interacted with
  events: 'input|blur',
  inject: true,
  validity: false,
  aria: true,
  i18n: null, // the vue-i18n plugin instance
  i18nRootKey: 'validations' // the nested key under which the validation messsages will be located

Vue.use(VeeValidate, config);
Config Name Default Description
errorBagName errors The name of the `ErrorBag` object that will be injected in each of Vue's instances' data.
fieldsBagName fields The name of the Fields (flags) object that will be injected in each of Vue's instances' data.
delay 0 The default debounce time for all inputs (only affects validations).
locale en The default language for the validation messages.
dictionary null A dictionary to be merged with the validators dictionary. (Check the [custom messages](rules.html#custom-messages) and [localization](localization.html) sections.)
strict true Fields that have no rules will fail validation unless `strict` is set to false.
classes false Applies automatic classes on inputs or components root elements being validated.
classNames { touched: 'touched', // the control has been blurred untouched: 'untouched', // the control hasn't been blurred valid: 'valid', // model is valid invalid: 'invalid', // model is not valid pristine: 'pristine', // control has not been interacted with dirty: 'dirty' // control has been interacted with } The classes to be applied depending on the state of the input.
events input|blur Pipe separated list of the default event names that will be listened to, to trigger validation. If an empty string is provided, it will disable all listeners.
inject true Specifies if a validator instance should be injected automatically for all components. (See [Component Injections](advanced#injections) for more information.)
validity false Set custom validity (Constraint validation)[] on native HTML inputs.
aria true Sets `aria-invalid` and `aria-required` on native HTML inputs.
i18n null The `vue-i18n` instance, if provided will integrate vee-validate with the i18n plugin and will use it to produce the error messages instead of the built in dictionary.
i18nRootKey validations The key name of the validation messages for each locale.

Custom Messages

You might need to overwrite the error messages, or add new ones. The Validator class and its instances provide a localize method, which will merge the messages with the internal dictionary, overwriting any duplicates.

Any merges will have an effect on all validator instances as the messages dictionary is shared.

import { Validator } from 'vee-validate';
const dictionary = {
  en: {
      alpha: () => 'Some English Message'
  ar: {
    messages: {
      alpha: () => 'Some Arabic Message'

// Override and merge the dictionaries

const validator = new Validator({ first_name: 'alpha' });

validator.localize('ar'); // now this validator will generate messages in Arabic.

You must provide the messages in an object path like: dictionary.locale.messages.

Usually, you would structure your language files for your app rather than adding hardcoded strings like the example above, check the localization guide for more info.

Custom Attributes

Like the custom messages, the validators share a dictionary containing the attribute names, for example if you want to use "Email Address" instead of "email" in your error messages, this can be easily achieved by including an attributes object in the dictionary.

Unlike messages, no attributes are included in the default dictionary.

import { Validator } from 'vee-validate';
const dictionary = {
  en: {
    attributes: {
      email: 'Email Address'
  ar: {
    attributes: {
      email: 'البريد الاليكتروني'


If the attribute is not found for the current locale, it will fallback to the binding expression or the field name. If you use the data-vv-as attribute, it will take precedence over the internal dictionary.

Field-specific Custom Messages

You might need to provide different messages for different fields, for example you might want to display an error message for the email field when it's required, but a different messsage when the name is required. This allows you to give your users a flexible experience and context aware messages.

To do this you would need to add an object to the dictionary called custom like this:

const dict = {
  custom: {
    email: {
      required: 'Your email is empty' // messages can be strings as well.
    name: {
      required: () => 'Your name is empty'

Notice that the custom object contains properties that represent the field names, those field names objects contain properties that represent the validation rule that its value will be used instead of the default one.

Then you would need to add the dictionary we just constructed to the current validators dictionary like this:

Validator.localize('en', dict);
// or use the instance method
this.$validator.localize('en', dict);

That's it. One thing to keep in mind is to place any dictionary related operations in your code before it actually needs it to avoid uneccessary merges. For example, a good common place is in your app entry point or setup script, conversly, a poor choice would be a component lifecycle hook like mounted since the validator dictionary is kept globally for all instances.

By default, any unspecified rules for the specific field messages will fallback to the already included ones, so you only need to define the custom messages you only need.