I'm trying to determine the best way to inform the User that an input accepts certain special characters. Alphanumerics are simple enough, but I feel like I'm losing clarity when I get to characters such as . and -. One style I've tried is this:

Valid characters include A-z, 0-9, and (._-).

Where the parenthesis wrap the valid characters, but when the parenthesis are not valid, it seems too easy for them to be mistaken as part of the list.

The style I'm leaning towards is the following:

Valid Characters include A-z, 0-9, '.', '_', and '-'.

But I feel as though the single quotes clutter things up, and makes it easy to lose yourself in the list, especially as it grows. Is there any way to convey this information that's accepted as 'better', or are there in fact better ways to go about this entirely?

  • This is very closely related to another question about validation but I'm not sure if it's a duplicate. It might be. Commented May 19, 2014 at 20:35
  • @AndrewLeach It's definitely similar, but that question seems more related to When validation information should be displayed. I was concerned with verbiage. Unfortunately in my case, I have no choice as to the when.
    – MildWolfie
    Commented May 19, 2014 at 21:41
  • 5
    For better user experience, a good rule of thumb for presenting such complex requirements is to question the actual requirements. Is it so absolutely neccessary to have this exact limitation? Could you go out of your way and change your systems (perhaps re-encoding or 'escaping' their original input) so that there aren't arbitrary sets of 'valid characters' anymore? The best UX for this message would be no message at all, except when completely abnormal edge cases are encountered ("Please don't input 2 gigabytes of text here").
    – Peteris
    Commented May 20, 2014 at 7:48
  • 2
    Personally, I would really like it it if it just said "Your username must match the pattern insert-relevant-regex-here," because then there is no ambiguity about allowed characters, Unicode, allowed lengths, or any weird restrictions that some sites seem to like. Unfortunately, most users do not know regular expressions, so this is unlikely to ever happen. Commented May 20, 2014 at 20:57
  • 3
    Although the best solution is actually "don't impose these restrictions on your users". Commented May 20, 2014 at 21:04

12 Answers 12


Clutter is problematic. Emphasizing the valid characters might be enough. E.g.:

Valid characters are A-Z a-z 0-9 . _ -.

Displaying them with different color might also help.


Here is some advice :

  • forbid characters only if it is absolutely necessary (I hate when I cannot use _ in my nickname)
  • display a message only to the user who tries to use one of these. Other users won't be bothered
  • if the user enter a forbidden caracter, just don't consider it and explain him why.


download bmml source – Wireframes created with Balsamiq Mockups

  • 15
    This is good feedback, but trial-and-error can get pretty annoying. I'd say give the list and do this. Commented May 19, 2014 at 19:19
  • 19
    I disagree. I hate it when I spend five minutes thinking of a new password for a site, only to be told that it’s unacceptable after I’ve typed it. Commented May 19, 2014 at 20:35
  • 6
    @Scott: I think that is where his first point comes in. There just shouldn't be a limitation on characters for passwords in the first place.
    – fresskoma
    Commented May 19, 2014 at 22:42
  • 2
    Showing all characters you don't allow in the first attempt would work better. imgur.com/AEoYUTJ
    – AKS
    Commented May 20, 2014 at 16:13
  • 2
    I really get angry when I’m not being told upfront which characters are (generally; eMail address validation is probably not a good example for this) valid. I consider this bad advice for the general case. Do show all valid characters first.
    – mirabilos
    Commented May 21, 2014 at 8:05

You could display blocks of each character type, like this:

Allowed characters: A-Z a-z 0-9 - _ .


I would suggest to mention about the characters that are not allowed, because number of invalid characters is always lesser for any required input. This will help to reduce clutter. See the given example from windows explorer.

enter image description here

  • 5
    In my case the number of valid special characters is actually the smaller set. I know that's not the norm, though, so it's a good answer for most cases.
    – MildWolfie
    Commented May 20, 2014 at 12:21

I'd leave out A-z and possibly even 0-9 as these should be obviously allowed. For the additional characters I'd go with their names rather than the symbols

You may also use underscore, dash and period.

  • 4
    It's worth giving the symbols as well if US English isn't guaranteed to be your users' instinctive language (in UK English these would be underline/underscore, hyphen and full stop, goodness knows about some of the rest of the commonwealth). It's technically not a dash but a hyphen, I'm guessing you don't want the user entering U+2013!
    – Chris H
    Commented May 19, 2014 at 19:34
  • 5
    Good point. How about: "You may use period (.), underscore (_) and dash (-)." This resolves ambiguities and it still looks nicer (imho) than a list of symbols only. (Note, that I moved period to the front to avoid confusion with the period of the sentence). Commented May 20, 2014 at 7:22
  • @ChrisH For a non-English user A-z may include all the accented letters as they're sorted in their alphabet, so it doesn't help much. Something like "Latin letters without diacritics" would be more precise but probably also more confusing.
    – maaartinus
    Commented May 25, 2014 at 14:08
  • @maaartinus - even more to consider when it comes to international users! How about "A-z (no accents)"?
    – Chris H
    Commented May 25, 2014 at 16:33
  • @ChrisH Someone could claim, that A-z includes also the six non-letters in between, but yes. It's short and clear (unless someone wants to misunderstand).
    – maaartinus
    Commented May 25, 2014 at 17:17


You should show all valid or all invalid characters before the user starts to type into the field. This should be a hint. Keep it short, easy to understand and straightforward.



download bmml source – Wireframes created with Balsamiq Mockups

In depth explanation

Example placeholders

Use fields with a placeholder that shows a valid example input. Example placeholders indicate the preferred format of the input. This could help for example in a telephone number field.

Message on focus

Display a fixed label or a popup bubble when the user enters the field.
The user will see the hint before he starts to enter the input, so he can think of a different value if the one he wanted to entry is incorrect. This also solves the possible question that a user would ask before giving the input: "what should I write over here? Will my input correct?".

Short and bold character list

Use short form of the valid characters like "a-z" not something like "alphanumerical only".
It's much easier to oversee and understand the accepted characters. You don't have to find out the meaning of the words like: "ok, alphanumerical characters are characters from a to z with numbers". Also clarifies obscurity like: "are uppercase letters allowed?".

I would also recommend @NonNumeric's solution with using bold on the allowed character list. This guides attention to the essence of the popup message.

Feedback on blur

After the user filled the field and the focus is lost, you should validate the field.

  • If the input is valid, show a check mark that indicates the valid input.
  • If the input is invalid, leave the popup there and make it or the user field (or both) red, so it will indicate that something went wrong.

Thanks to this, if the user missed the guide before typing, he has a feedback after his input. The errors/check marks also simplify the overview of the filled form.


One way to deal with this is to not say anything at all at first and then let the user know when a disallowed character is entered. If you use in-line validation and apply after each character input, the user (almost) won't even need to be notified of which character was forbidden.

It depends on what should go in the field. If the data that should go in the field follows a certain form (e.g. a postal code or something), there is a very limited set of characters that should end up there. Type-Os and very alternative ways of typing the data will be handled by the error message and the rest will just float by without even noticing.

It might be though, that the field is made for data that has less conventions around its format. In such case, the number of erroneous inputs may reach unacceptable levels and instructions pre-input is required.

Both in the inline error message and in the case where an info text is needed, I prefer writing "Letters and numbers" rather than "A-Z, a-Z, 0-9" because it's a lot easier to make sense of, and you can save the clutter for the special characters.

Ex: Please, use only letters, numbers and these special characters ( _ . - )

  • 2
    I disagree. I hate it when I spend five minutes thinking of a new password for a site, only to be told that it’s unacceptable after I’ve typed it. Commented May 19, 2014 at 20:36
  • Well, that's not exactly what I wrote now, was it...?
    – Babossa
    Commented May 19, 2014 at 21:06
  • Well, you did say, “not say anything at all at first and then let the user know when a disallowed character is entered”. Commented May 19, 2014 at 23:23
  • ...when suitable, yes. I also said that fields for data with less convention around its format should use a different approach. Password is for sure one of them.
    – Babossa
    Commented May 20, 2014 at 4:58

I would say that your best bet is to use a table-like structure to clearly label and isolate each rule:


    padding:3px 6px 3px 6px;
    border:solid 1px #000;


<h3>Allowed characters</h3>
    <tr><td>Alphabet: lower-case and UPPER-case</td><td>A through Z<br>a through z</td></tr>
    <tr><td>Numbers</td><td>0 through 9</td></tr>
    <tr><td>Punctuation: period, underscore, hyphen</td><td>.<br>_<br>-</td></tr>


So now if your list grows then you do not have to worry about future characters messing with any sort of formatting you may have chosen for previous characters.

  • 1
    This is very clear, but also extremely verbose. In most web forms I encountered, there would simply be no space to (dynamically) insert this kind of table when invalid characters are entered. Commented May 20, 2014 at 8:25
  • @user1884155 I agree to a very basic an narrow extent. If I were to implement this then my error message would simply read something like Invalid characters detected<br><a href="open a modal window when clicked">Click to view list of allowed characters</a>
    – MonkeyZeus
    Commented May 20, 2014 at 12:51
  • 1. This describes how to implement a solution rather than how to present the information. 2. It is a bad implementation. Table-based layout is not the correct way to present information that is not semantically tabular data. It's a bad short-cut that can present all sorts of page layout issues. You can achieve the intended layout using proper CSS and HTML markup
    – Bill Dagg
    Commented May 22, 2014 at 19:08
  • @BillDagg Yes I know <table>'s suck and I wouldn't use it in a real implementation but my answer does show how you can clearly present the information. The other solutions presented here are relying on a user's pre-disposition to identifying what bold means and when punctuation begins vs. allowed chars begin. I would imagine that an older person is going to have trouble with the web form in the first place so why create a cryptic design that may/may not be recognized? Also please read my first comment to get an idea of how to implement this without killing your page layout.
    – MonkeyZeus
    Commented May 22, 2014 at 20:06
  • @BillDagg I think tables are perfectly fine for enumerations, and in the answer above there is an enumeration of size 3. I also think that in the context of this question (and the answer provided) a comment about the misuse of tables is out of place. Commented Jun 4, 2014 at 8:45

If you just allow all utf8 characters as input, you don't need to worry about how to explain it to the user. And it will save you a big headache when going global with your app/website.

If they have to enter an email, you can write "this email address is not valid according to internet standard RFC ". That is much easier and people will understand why they need to enter only those characters instead of thinking you are a meany.

  • 11
    I don't know that "most people" know what an RFC is? Commented May 19, 2014 at 18:41
  • According to which RFC?
    – Bergi
    Commented May 21, 2014 at 8:43
  • @CharlesWesley RFC: Request For Coitous duhhhh =)
    – MonkeyZeus
    Commented May 22, 2014 at 20:10

In order to avoid all the clutter, but to still provide all the descriptive information you want ahead of time, you could have a "link" near the input field that says something like "What characters are valid here.". When a person moves their mouse to (hovers their mouse over) the link, a "tooltip" is shown that describes what is valid, in whatever detail you want.


If space isn't an issue, then use a vertical list with word and actual cues.

You can use

  • Numbers (0-9),
  • Letters (A-Z and a-z),
  • Underscores (_),
  • Hyphens (-), and
  • Periods (.)

In any case, explain the valid characters before the user enters data, not after submission or upon typing.


If you use the word "Alphanumeric" instead of writing A-Z and 0-9, it will reduce the amount of clutter and be clearer to the user.

  • The trouble with using the word 'Alphanumeric' is that it doesn't include . , _ etc.
    – JonW
    Commented May 19, 2014 at 17:33
  • 3
    Also for average user it takes a significant amount of cognitive effort to go from 'Alphanumeric' to characters a-z 0-9 and even then tiny doubt about A-Z.
    – Jason A.
    Commented May 20, 2014 at 20:41

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