^(?=.{1,10}$).*

^(?=[\S\s]{1,10}$)[\S\s]*

It is important that the ‹$› anchor appears inside the lookahead because the maximum length test works only if we ensure that there are no more characters after we’ve reached the limit. Because the lookahead at the beginning of the regex enforces the length range, the following pattern can then apply any additional validation rules. In this case, the pattern ‹.*› (or ‹[\S\s]*› in the version that adds native JavaScript support) is used to simply match the entire subject text with no added constraints.

The first regex uses the “dot matches line breaks” option so that it will work correctly when your subject string contains line breaks. See Recipe 3.4 for details about how to apply this modifier with your programming language. Standard JavaScript without XRegExp doesn’t have a “dot matches line breaks” option, so the second regex uses a character class that matches any character. See Any character including line breaks for more information.

^\s*(?:\S\s*){10,100}$

By default, ‹\s› in .NET, JavaScript, Perl, and Python 3.x matches all Unicode whitespace, and ‹\S› matches everything else. In Java, PCRE, Python 2.x, and Ruby, ‹\s› matches ASCII whitespace only, and ‹\S› matches everything else. In Python 2.x, you can make ‹\s› match all Unicode whitespace by passing the UNICODE or U flag when creating the regex. In Java 7, you can make ‹\s› match all Unicode whitespace by passing the UNICODE_CHARACTER_CLASS flag. Developers using Java 4 to 6, PCRE, and Ruby 1.9 who want to avoid having any Unicode whitespace count against their character limit can switch to the following version of the regex that takes advantage of Unicode categories (described in Recipe 2.7):

^[\p{Z}\s]*(?:[^\p{Z}\s][\p{Z}\s]*){10,100}$

PCRE must be compiled with UTF-8 support for this to work. In PHP, turn on UTF-8 support with the /u pattern modifier.

This latter regex combines the Unicode ‹\p{Z}› Separator property with the ‹\s› shorthand for whitespace. That’s because the characters matched by ‹\p{Z}› and ‹\s› do not completely overlap. ‹\s› includes the characters at positions 0x09 through 0x0D (tab, line feed, vertical tab, form feed, and carriage return), which are not assigned the Separator property by the Unicode standard. By combining ‹\p{Z}› and ‹\s› in a character class, you ensure that all whitespace characters are matched.

In both regexes, the interval quantifier ‹{10,100}› is applied to the noncapturing group that precedes it, rather than a single token. The group matches any single nonwhitespace character followed by zero or more whitespace characters. The interval quantifier can reliably track how many nonwhitespace characters are matched because exactly one nonwhitespace character is matched during each iteration.

^\W*(?:\w+\b\W*){10,100}$

In Java 4 to 6, JavaScript, PCRE, Python 2.x, and Ruby, the word character token ‹\w› in this regex will match only the ASCII characters A–Z, a–z, 0–9, and _, and therefore this cannot correctly count words that contain non-ASCII letters and numbers. In .NET and Perl, ‹\w› is based on the Unicode table (as is its inverse, ‹\W›, and the word boundary ‹\b›) and will match letters and digits from all Unicode scripts. In Python 2.x, you can choose to make these tokens Unicode-based by passing the UNICODE or U flag when creating the regex. In Python 3.x, they are Unicode-based by default. In Java 7, you can choose to make the shorthands for word and nonword characters Unicode-based by passing the UNICODE_CHARACTER_CLASS flag. Java’s ‹\b› is always Unicode-based.

If you want to count words that contain non-ASCII letters and numbers, the following regexes provide this capability for additional regex flavors:

^[^\p{L}\p{M}\p{Nd}\p{Pc}]*(?:[\p{L}\p{M}\p{Nd}\p{Pc}]+↵
\b[^\p{L}\p{M}\p{Nd}\p{Pc}]*){10,100}$

^[^\p{L}\p{M}\p{Nd}\p{Pc}]*(?:[\p{L}\p{M}\p{Nd}\p{Pc}]+↵
(?:[^\p{L}\p{M}\p{Nd}\p{Pc}]+|$)){10,100}$

PCRE must be compiled with UTF-8 support for this to work. In PHP, turn on UTF-8 support with the /u pattern modifier.

As noted, the reason for these different (but equivalent) regexes is the varying handling of the word character and word boundary tokens, explained more fully in Word Characters.

The last two regexes use character classes that include the separate Unicode categories for letters, marks (necessary for matching words of many languages), decimal numbers, and connector punctuation (the underscore and similar characters), which makes them equivalent to the earlier regex that used ‹\w› and ‹\W›.

Each repetition of the noncapturing group in the first two of these three regexes matches an entire word followed by zero or more nonword characters. The ‹\W› (or ‹[^\p{L}\p{M}\p{Nd}\p{Pc}]›) token inside the group is allowed to repeat zero times in case the string ends with a word character. However, since this effectively makes the nonword character sequence optional throughout the matching process, the word boundary assertion ‹\b› is needed between ‹\w› and ‹\W› (or ‹[\p{L}\p{M}\p{Nd}\p{Pc}]› and ‹[^\p{L}\p{M}\p{Nd}\p{Pc}]›), to ensure that each repetition of the group really matches an entire word. Without the word boundary, a single repetition would be allowed to match any part of a word, with subsequent repetitions matching additional pieces.

The third version of the regex (which adds support for XRegExp, PCRE, and Ruby 1.9) works a bit differently. It uses a plus (one or more) instead of an asterisk (zero or more) quantifier, and explicitly allows matching zero characters only if the matching process has reached the end of the string. This allows us to avoid the word boundary token, which is necessary to ensure accuracy since ‹\b› is not Unicode-enabled in XRegExp, PCRE, or Ruby. ‹\b› is Unicode-enabled in Java, even though Java’s ‹\w› is not (unless you use the UNICODE_CHARACTER_CLASS flag in Java 7).

Unfortunately, none of these options allow standard JavaScript or Ruby 1.8 to correctly handle words that use non-ASCII characters. A possible workaround is to reframe the regex to count whitespace rather than word character sequences, as shown here:

^\s*(?:\S+(?:\s+|$)){10,100}$

In many cases, this will work the same as the previous solutions, although it’s not exactly equivalent. For example, one difference is that compounds joined by a hyphen, such as “far-reaching,” will now be counted as one word instead of two. The same applies to words with apostrophes, such as “don’t.”