I have some information to enter in a text box. The data is structured and only some sequences are valid. For a phone number, for instance, a letter such as A is invalid.

So should I intercept keyboard events and prevent typed letters from reaching the text box, or should I draw some red squiggly lines (or another visual cue) to let my user know the letter is not acceptable? Which is a better user experience?

  • 1
    In general I would say preventing a user to ever make the error is better. But when you speak about entering data and preventing the user from entering 'wrong' keystrokes, I would argue against it.. Maybe rephrase your question a bit?
    – Lode
    Commented Sep 2, 2010 at 19:46
  • Excellent suggestion, thanks. I edited the question.
    – louisgab
    Commented Sep 2, 2010 at 20:00

7 Answers 7


Overriding a user's control of his or her computer will always be an interruption, and often be perceived as an invasion, of that user's workflow. The web site "isn't supposed to" have control of our computers, so exerting such control will be at least a little alarming.

That said, you broach a really important topic, being the importance of letting a user know their entry is invalid before they fill out an entire set of fields and submit them.

The approach I've found to be the least-intrusive but provide the quickest turn-around response is the flow below.

alt text

Essentially, wait for them to fill out their first field, then as they click/tab around a new field (or a field that has been invalidated), check the field that was just completed. If the field that was just completed is valid, print an unobtrusive "good" icon next to it (green, checkmark, happy face, you get the idea). If it fails the validation rules, discretely print a "bad" icon (red, "X", etc.) and a short line about what failed.

But remember, do not interrupt their workflow:

  • No pop-ups
  • no overlays

When they're finished with the field they moved to, they'll either go back to the invalid field or move on and go back later. Either way, they'll see that they have an edit to make but can do it on their own time.

In the end, they'll have a completely valid form before ever submitting, which means

  1. They'll only have to submit once
  2. They don't spend time getting mad or frustrated when their submission "fails"
  3. They'll like your site more
  4. Everyone will have cake
  • 2
    +1 I really like this approach as it doesn't force itself on the user. Gels very nicely with the approach I found somewhere else with regard to data entry: spot invalid data, mark it as such, but allow it to be saved so users can continue their work at a later date. However, do prevent any use of the data which would require all data to be valid. In app used to submit tax information to the tax agency for example, all kinds of invalid and inconsistent data could be entered and saved, but you had to resolve all errors before you could submit the information to the tax agency. Commented Sep 3, 2010 at 20:08
  • +1 to your comment—I really like your extension of the concept. The key is where the interruption is activated in your example. As long as the markings next to the invalid/inconsistent data are just descriptive enough and are passive, it's a good substrate for building a potentially complicated or intricate form.
    – Matthew
    Commented Sep 3, 2010 at 20:15

Being on both ends of using a form, here are some guidelines I prefer:

  • User inputs should hardly ever be prevented. Meaning if I type the letter 'A' in a phone number field, I would expect to see that 'A'.
  • I begin my text field validation on a onBlur() event, and no sooner than that. This gives the user a chance to fix that mis-typed 'A' before I show an error message. Allowing the user to correct an error while still in the input field provides one less chance for an obtrusive "hey, you messed up, dude" kind of message.
  • I agree with your first comment
    – Eran Bar
    Commented Jul 1, 2018 at 11:03

If you prevent invalid characters while they type, they could potentially think that their keyboard is malfunctioning. User's like things to work the way they expect them to. If you are going to prevent certain characters on key press, at the very least you should also display an error message near the input at the same time. This way they know why it isn't typing.

Another thing that can get annoying is when you just finished filling out a long form and the site uses server side validation so you have to go back through the form to find what's wrong. I like to use client side validation primarily but fall back on server side. I will display an error either as they are typing or when the input loses focus. That way the user knows right away that there is an issue and knows exactly what the problem is.


I find that preventing users from making mistakes is always 10x harder than I originally thought. Example: Someone's phone number may have an extension, like x2333. I've used the jQuery input mask plugin for credit cards and that worked well. I use Auto-suggest whenever possible.

In any complex system, you will have circumstances that are expensive to detect inline and you need to tell them after the fact. To me, the answer is case-by-case and make sure you cover every edge case.

  • Yes indeed preventing mistakes often seems easy at first, but sometimes APIs just won't allow you to do it elegantly.
    – louisgab
    Commented Sep 3, 2010 at 13:41

I would suggest a hybrid of both approaches, but only for strictly-validated fields like phone numbers (SSN, zipcodes, etc ... anything that must be numeric by definition).

Track each keystroke and, when the user types an invalid character, show it ... but immediately signal that something's wrong. Maybe turn the input field red and display a "Please enter numeric characters only" to the right of the field.

Blocking input is a no-no because it can be misinterpreted by the user. They might assume a problem with their machine or input device, not that they weren't supposed to type a letter in a numeric entry box.

Validating after the input is completed can be annoying. Particularly with fields like those used in password creation. Some sites require 6-character passwords with only alphanumeric characters. Others require 9-character passwords and allow any character (including !@#$% and such). Typing a password and only finding out after I've typed it is the most annoying form type I've found and has actually turned me away from several services.

Providing dynamic feedback as the user enters data helps them

  1. Know which field had the error while they're still in the field
  2. Proactively correct input errors before submitting data
  3. Learn from the experience as they go

Blocking input fails on all 3 accounts. Highlighting validation errors after the textbox is filled in fails on all 3 as well.


It depends on the case. If possible use Auto-suggest. If you intercepts user's input, an immediate feedback is crucial. One of the possible solutions is "clue box" that pops up immediately after key is intercepted. You can see it on Windows login screen, it pops up if you press $ sign for instance.

  • Immediately responding to input will be alarming for the user because they won't be expecting it. While the system is able to analyze input and respond instantaneously, humans generally cannot. Such feedback is then exotic rather than organic and causes mistrust or confusion. Even though we all know there really isn't a person talking to us through the form's page, users will feel more comfortable if they feels as if the site "thinks" about what they entered and responds in human-time rather than computer-time.
    – Matthew
    Commented Sep 2, 2010 at 21:47
  • I don't think it's necessarily bad. With appropriate feedback users are less likely to be surprised and assume that the rejection is a consequence of a defective software or some other unexpected error. We've tested it and in most cases there weren't any serious issues.
    – Janko
    Commented Sep 3, 2010 at 21:18

As with most things..depends on context. I have a more specialized take on the topic. Most of the applications I, or my group, work on are technical in nature and are only used by the reasonably trained. As such we can place more responsibility and freedom in the hands of the users than you could with the general public. Briefly, some of the guidelines we use...

  • Disregard any invalid entry....block invalid keystrokes.
  • Indicate invalid fields, a state that should be all but impossible, by contrast and color*.
  • Focus is always under user control. Do not trap the user or prevent a change of focus.
  • Never throw a modal warning/error box. Ever.
  • Never ask the user questions. Software is a tool not a person. Yes I am sure.
  • The Enter/Return keys always mean: Accept changes and move on. Do not change this by using focus on a cancel/exit button as the default on Enter.
  • The Escape key always means: Discard and exit.
  • Provide auto-completion whenever possible.
  • Provide short-cut entry for numerics that have a min/max limit. e.g. If a valid value is between 0.12 and 100.387 then entries greater that 100.387, like 999, are taken as 100.387, etc.
  • Establish very clear black and white rules on behavior..rules the user can understand. If this becomes overly complex...re-think it.

Almost all of the examples are user requested and, yes...implementation is sometimes a real bear/nightmare/killer but rarely impossible.

Caveat: Again, these examples are given in the context of a vertical system with a technical user base....not a web general public form, etc. Your mileage my vary.

*Except red. In our business red means: Danger you could be killed...or worse.

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.