I find a problem on the MVC4 project I am working on now, using Fluent Validation, in that some validations are delegated to the jQuery client side validation, while some, such as the NotNull rule for dropdowns, and some conditional validations based on field values, must be done on the server.

This results in the user leaving some dropdowns, and some textboxes blank, or selecting a certain value in a dropdown. They then press Submit and get messages for the client side validations, which they correct. They then click submit again, and again get other messages for the server side validations, which they must the correct and click submit again.

I have about 5% of my pages where server side validation isn't required, so I figure turning client side off will make for a much better UX. They user will get all their validation messages at once, can attempt all corrections at once, resubmit.

  • 7
    Your client side validations only appear on submit? So if a user is filling out a form and tabbing from one field to the next, the client side validations don't appear then?
    – Tarek
    Commented Feb 12, 2013 at 10:38
  • 2
    If the user sees no benefit of the client-side over the server-side then that's a bit confusing. Users don't know/care if validation is client or server side, they just care about the validation information itself.
    – JonW
    Commented Feb 12, 2013 at 10:56
  • 5
    Why would not null require server side validation?
    – Ben Brocka
    Commented Feb 12, 2013 at 13:20
  • 1
    For the user the best option would be validation on lost focus for every single input element - it doesn't matter whether this technically happens on the server or on the client side.
    – Gabriele
    Commented Feb 12, 2013 at 16:10
  • 3
    Here are the results of a study about different forms of inline validation: alistapart.com/articles/inline-validation-in-web-forms And here's another interesting article about inline validation in general: uxdesign.smashingmagazine.com/2012/06/27/… Maybe it's helpful...
    – Gabriele
    Commented Feb 12, 2013 at 16:20

10 Answers 10


I use the rule server-side validation for security and client side validation for usability.

I can't trust any client, but I can write a standard client which quickly (without the network) validates inputs, so the user can get a response sometimes even while typing.

This also minimizes the wrong requests my client sends to my server.

-- EDIT --

What I want to say is:

You can do the validation without spending any time to client side validation and get decent results.


  • Just implementing one validation.
  • No 2 level error messages, just one from the server.


  • For every faulty input you get one faulty request to your server, even just the client you implemented is used.
  • The users have to wait for a server response to know what's wrong.

What you need is probably implementing two validators, which take the same configuration, so you don't have to write the configuration for client and server. Which would eliminate the problem with the 2 level-errors and get you the benefits of client side validation.

  • This does not solve the problem. You still have two validation circles, if you can not validate something client side.
    – kontur
    Commented Feb 12, 2013 at 11:25
  • 2
    The only problem I can see here is, that you have to get the two circles doing the same validation, which doesn't seem like a dealbreaker to me.
    – K..
    Commented Feb 12, 2013 at 11:50
  • 1
    One more point, server validation wipes password fields which is not great user experience. +1 for everything else
    – Andrey
    Commented Feb 12, 2013 at 15:58
  • 2
    Remember you can use the server side validation through ajax calls as well. Meaning you'd be able to use the exact same rules in both places. Yes there's a short delay compared to a fully client side validation, but not much.
    – Svish
    Commented Feb 12, 2013 at 18:50
  • 2
    Or you could use Node.js and run the exact same code for client and server validation...
    – zzzzBov
    Commented Feb 12, 2013 at 19:02

This is annoying. Your user fills out the form, submits, and gets back "3 mistakes". He corrects those 3 mistakes, submits, and gets back "2 new mistakes" in fields he hasn't changed meanwhile. His reaction:

"Why did you not tell me about those 2 mistakes in the first place"?

And he's right.

Clientside validation was meant to help the user by providing faster feedback. Waiting for the user to click "submit" makes you lose most of that edge: you only save the round-trip time to the server, which these days often is minimal. Especially when it comes with the cost of two submits, your clientside validation is not helping the user, but annoying him.

Two fixes:

1/ Have the clientside solution be immediate: as soon as a user enters a wrong email address (field goes out of focus), give a clue (show a box, color the field red) that the email address has the wrong format and will not be accepted by the server anyway.

2/ If the clientside solution cannot be immediate, disable it altogether. Have one serverside validation that catches ALL the errors, and shows them ALL at one (not stop at the first error, have the user fix that, repeat for every error).

In a perfect world, clientside verification catches every possible mistake a user can make, but we often know this is not possible. Users got used to this too: noone will get mad if the clientside validation only catches a subset of the mistakes the serverside validation catches.

This is why I often only code the 80% most common errors in the clientside, and leave the edge cases for the serverside. If a most common error can only be checked at serverside (eg "username already taken"), a small AJAX request can do wonders: while the user continues filling out the form, he'll notice his username was already taken and can change it to something else.

  • 1
    I appreciate your Pareto Law mentality.
    – hexparrot
    Commented Feb 12, 2013 at 18:21

I'm a huge fan of on-the-fly server validations.

When you're not dealing with huge amounts of data (large file uploads, etc), it's not too difficult to automatically AJAX-submit parts of a form to the server for validation. This is commonly seen in sign-up forms where users need to pick a unique username in addition to entering their email, password, etc.

Using the client + server validation model

  1. Enters a username "I-Love-Kittenz"
    • Client side error "You can't have special characters"
  2. Changes username to "ILoveKittenz"
    • Client side gives no error
  3. User submits form
    • Server side error "That username is already taken!"
  4. User is frustrated and tries another username

Using the on-the-fly server validation model

  1. Enters a username "I-Love-Kittenz"
    • Client polls server and gets error "You can't have special characters"
  2. Changes username to "ILoveKittenz"
    • Client polls server and gets error "That username is already taken!"
  3. Changes username to "ILoveK1ttenz"
    • Client polls server and gets OK
  4. User submits and is happy!
  • 2
    +1. This lets you put all your actual validation code on the server. All the client has to do is pass the input to the server-side validation method via AJAX, and then display the validation result to the user (if needed). That way you don't have validation code in two places. It also makes it easy to repeat the client-side validation after the form is submitted. Commented Feb 12, 2013 at 22:23
  • I'm becoming more convinced these days that this works best for most forms, especially with the ubiquity of AJAX, and the increased ease of coding asynchronous server calls in most development platforms. I'd leave full-page server side validation to very heavy, data intensive, entry forms (which are becoming less common, due to improved UX design practices). Commented Feb 18, 2013 at 18:07

Client side validation is usually desirable because it is fast. The validation gets done before the form is submitted. The user doesn't have to wait several seconds before the server responds.

Server side validation is usually required because users without javascript or malicious users could submit bad data without it.

Best practice is usually to have both do the same validation so that it is fast for users, but the server is protected from bad data.


The user need not know how or where something was validated.

Perform both validations and show both validations' erros in the same dialog. Doing so will remove the disappointing experience of having validated, corrected, and the validated and corrected again. The user right away knows what is wrong and knows to fix all the problems after the first error prompt.

  • Can you elaborate on how to show errors from both validations in the same dialog, when client validation is fast and server validation is slow? Do you wait to show the dialog until the response from the server is received, thus eliminating the benefit of fast client-side validation? I can think of some possible answers, but wanted to hear what you had in mind.
    – LarsH
    Commented Feb 12, 2013 at 15:31

You can do without client-side validation, but you cannot do without server-side validation.

No ifs, no buts.

If you want your site to get hacked, rely on client-side validation.

The client-side validation should be used to minimise the amount of errors that server-side validation will detect. It shouldn't be used instead of server-side validation.

However, if you rely on server-side validation, you can end up with a real mess, if the form is remotely complicated. So use both if you want the best result, or use server side only if you want ease of programming and a single point for your business rules. But never use client side only. Ever.

  • The OP isn't suggesting relying on Client Side validation only, in fact he's suggesting removing this validation altogether.
    – JonW
    Commented Feb 12, 2013 at 17:20
  • Well, he isn't suggesting it. However he also states: "I have about 5% of my pages where server side validation isn't required" and I took that to mean he relies on client side validation in thoses instances. My comments were made on that basis. Commented Feb 12, 2013 at 17:26

You should validate on BOTH client side and server side, see above answer for the reasons why. Your user will get a faster/responsive experience and your server will thank you for stopping invalid attempts before they are submitted.

I think you are having another problem: improper use or lack of knowledge of MVC 4 methods for validation:

  1. Yes, you can and should validate not null rule for dropdowns on the client side. See Required attribute.
  2. Yes, you can and should validate conditional rules on the client side. See Remote attribute and other custom attributes.
  • If you read my question properly you would have seen I'm using Fluent Validation, not attributes.
    – ProfK
    Commented Feb 12, 2013 at 18:16
  • sorry about that but from UX and best practices perspective: same answer applies. if your selected validation library does not support these basic features you should extend it so it does.
    – qbantek
    Commented Feb 12, 2013 at 18:52

Your problem isn't that you have both client and server-side validation. Your problem is that your client-side is validating things the server doesn't. That's completely pointless.

Client-side validation should never validate more than the server does. It's entire purpose is to not waste user-time/server-resources to discover something that can already be determined on the user's computer, which is that it will fail. The server very frequently validates things the client never should, by using business logic you wouldn't want exposed to the user.

So yes, any time you have something on the client setting stricter rules than the server, turn that off. If you're using a one-size fits all solution on the client-side, you might want to consider a solution that you can custom tailor to each scenario.


If you turn off client-side validation on all your pages as you suggest, will you really get all your validation messages at once? I find that in practice, most non-trivial forms require two-stage validation regardless of client vs. server side validation technique:

  1. Input validation - e.g. required fields
  2. Business rule validation - e.g. combination of selections are valid in the larger business context.

That being said, I gave up on client-side validation years ago. I found that the cons consistently outweighed the pros.


  • Duplicate programming effort (validation must be done on server as well), or reliance on libraries like FluentValidation to work the way you need them to.
  • Duplicate testing effort
  • Inconsistent user experience. i.e. client-side validation is usually nearly instant, almost jerky. While service-side validation has a delay.
  • ...


  • Faster for the user
  • Less load on the server

However, if you do go 100% server-side, you'll want to move from full page POSTs to Ajax POSTs, if you haven't already. That will make your request / response time much faster (in the event of validation failure, you only return e.g. a list of validation results, rather than needing to rebuild the whole page). Easier said than done, there aren't a lot of ready-to-go libraries / frameworks out there supporting this paradigm, but well worth the effort on many counts including validation we discuss here.


You say "They then click submit again, and again" which sounds more like a test case than a real situation.
In my experience, the users don't submit forms with that many errors, albeit this is not impossible.
Depending on your application, most users might walk through it without seeing any error messages, so any concern about the origin of the messages is void.
It's also void if the user sees a single message.
If my users were seeing several messages while trying to perforn a task, then I'd check my UI to find out why.

  • Yeah... um what?
    – Tim
    Commented Feb 12, 2013 at 18:55
  • Hi @Tim, what I'm trying to convey (no success) is the idea that although we devote usually more than 50% of the code lines to handle user "errors", that code is seldom used because the users are smart enough. And that, if they weren't, I'd blame more the UI than the users. That said, a small inconsistency in error reporting should not be an issue.
    – Juan Lanus
    Commented Feb 13, 2013 at 14:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.