We’ve just wrapped up a great series of posts from Chris Ferdinandi on modern form validation. It starts here. These days, browsers have quite a few built-in tools for handling form validation including HTML attributes that can do quite a bit on their own, and a JavaScript API that can do even more. Chris even showed us that with a litttttle bit more work we can get down to IE 9 support with ideal UX.
So what’s up with third-party form validation libraries? Why would you use a library for something you can get for free?
You need deeper browser support.
All “modern” browsers + IE 9 down is pretty good, especially when you’ve accounted for cross-browser differences nicely as Chris did. But it’s not inconcievable that you need to go even deeper.
Libraries like Parsley go down a smidge further, to IE 8.
You’re using a JavaScript framework that doesn’t want you touching the DOM yourself.
When you’re working with a framework like React, you aren’t really attaching event handlers or inserting anything into the DOM manually at all. You might be passing values to a form element via props
and setting error data in state
.
You can absolutely do all that with native form validation and native constraint validation, but it also makes sense why you might reach for an add-on designed for that. You might reach for a package like react-validation that helps out in that world. Or Formik, which looks to be built just for this kind of thing:

Likewise, there is:
- angular-form-validation or angular-validation for Angular
- ember-form-validation for Ember
- vee-validate for Vue
The hope is that these libraries are nice and lightweight because the take advantage of the native API’s when they can. I’ll leave that to you to look into when you need to reach for this kind of thing.
You’re compelled by the API.
One of the major reasons any framework enjoys success is because of API nicety. If it makes your code easy to understand and work on, that’s a big deal.
Sometimes the nicest JavaScript API’s start with HTML attributes for activation and configuration. Remember that native HTML constraint validation is all about HTML attributes controlling form validation, so ideally any third-party form validation library would use them in the spirit of progressive enhancement.
You’re compelled by the integrations.
They promised you it “Works with Bootstrap!” and your project uses Bootstrap, so that seemed like a good fit. I get it, but this is my least favorite reason. In this context, the only thing Bootstrap would care about is a handful of class names and where you stick the divs.
It validates more than the browser offers.
The browser can validate if an email address is technically valid, but not if it bounces or not. The browser can validate if a zip code looks like a real zip code, but not if it actually exists or not. The browser can validate if a URL is a proper URL, but not if it resolves or not. A third-party lib could potentially do stuff like this.
You’re compelled by fancy features.
- Perhaps the library offers a feature where when there is an error, it scrolls the form to that first error.
- Perhaps the library offers a captcha feature, which is a related concept to form validation, and you need it.
- Perhaps the library offers an event system that you like. It publishes events when certain things happen on the form, and that’s useful to you.
- Perhaps the library not only validates the form, but creates a summary of all the errors to show the user.
These things are a little above and beyond straight up form validation. You could do all of this with native validation, but I could see how this would drive appoption of a third-party library.
You need translation.
Native browser validation messages (the default kind that come with the HTML attributes) are in the language that browser is in. So the French version of Firefox spits out messages in French, despite the language of the page itself:

Third-party form validation libraries can ship with language packs that help with this. FormValidation is an example.

Conclusion
I’m not recommending a form validation library. In fact, if anything, the opposite.
I imagine that third-party form validation libraries are going to fall away a bit as browser support and UX gets better and better for the native APIs.
Or (and I imagine many already do this), internally they start using native APIs more and more, then offer nice features on top of the validation itself.
I was using standard html form validation in Mozilla firefox, which was great and it worked. When I tried it in safari it just ignored all the validation which was very annoying.
However I didn’t get a third party plugin. I was already using jQuery and so I wrote my own validator plugin which works quite nicely.
Sometimes I write my own plugin because if I need to modify it later I know how it works. When you use somebody elses plugin and need to add a feature it is a lot harder.
There seems a bit of confusion in this article about 3rd-party validation and server-validation, especially with validating email/URL validity. Sure, you can use a 3rd-party, but there’s always server-side validation in there somewhere.
A lot of this article feels like a push at doing everything client-side, and relying on 3rd parties to do the things that you might need a server for. That kind of push only results with less developers who know server-side tech, not really a great place to be.
HTML5 validation allows invalid emails without proper domain extension like invalid@email
That alone justifies third party validation.
Here on this commenting form for instance you use default validation for required forms but you rely on server side tools for proper email validation.