Special characters in passwords: UX best practices
What is a special character in a password? It is any character that is not a letter (A to Z, a to z) or a digit (0 to 9). On a standard US keyboard that gives you 32 symbols plus the space: ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ { | } ~ plus the backtick. When a sign-up form asks for “at least one special character” or “a symbol”, any one of these counts.
Updated August 2026. NIST’s current password guidance (SP 800-63B) says to accept all printable ASCII and Unicode characters, including spaces, and not to impose composition rules such as “at least one symbol”. The advice below to allow every special character is now the official recommendation, not just a UX preference.
You cannot control users’ behaviour and therefore it is always best to give users the necessary controls. Passwords are currently the most universal way to authenticate. All special characters in passwords should be allowed.
In order to make passwords more secure, many websites are now requiring users to include special characters in their passwords. However, many users are still not including special characters in their passwords, because they do not know how to create them or they do not know which characters are allowed.
As a UX Designer, you should design a system that allows users to add all visible special characters. Adding visual feedback will make it easier for users to create strong passwords and will also make the passwords more secure.
Including special characters in passwords makes them more difficult to guess. In addition, including special characters can also make passwords more secure against brute force attacks.
Some websites only allow users to include a limited number of special characters in their passwords. This can be confusing for users and can lead to them using weaker passwords.
The full list of password special characters
This is the set OWASP lists as password special characters: the punctuation on a standard US keyboard, plus the space.
| Character | Name | Character | Name |
|---|---|---|---|
| (space) | Space | ; | Semicolon |
| ! | Exclamation mark | < | Less than |
| " | Double quote | = | Equals |
| # | Hash / number sign | > | Greater than |
| $ | Dollar sign | ? | Question mark |
| % | Percent | @ | At sign |
| & | Ampersand | [ | Left square bracket |
| ' | Apostrophe / single quote | \ | Backslash |
| ( | Left parenthesis | ] | Right square bracket |
| ) | Right parenthesis | ^ | Caret |
| * | Asterisk | _ | Underscore |
| + | Plus | ` | Backtick / grave accent |
| , | Comma | { | Left curly brace |
| - | Hyphen / minus | | | Vertical bar / pipe |
| . | Full stop / period | } | Right curly brace |
| / | Forward slash | ~ | Tilde |
| : | Colon |
Letters with accents (é, ñ, ü), other alphabets and emoji are not on this list, but they are still valid password characters under current NIST guidance. Whether a particular site accepts them is down to how it was built, which is exactly the UX problem.
What the password field should do
NIST’s SP 800-63B (section 3.1.1.2) is specific here, and it is good news for users:
- Accept everything. Verifiers should accept all printing ASCII characters and the space, and should accept Unicode, counting each code point as one character.
- Do not force a symbol. Verifiers “SHALL NOT impose other composition rules”, such as requiring a mix of character types.
- Ask for length instead. At least 15 characters when the password is the only factor, at least 8 when it is part of multi-factor sign-in, and a maximum of at least 64.
- Check against a blocklist of common and breached passwords rather than inventing rules.
If a legacy backend really does reject some symbols, say which ones next to the field before the user types, not in an error after they submit. A rule people discover by failing is the worst version of the rule. Our guide to form error messages covers how to word it when you have to show one, and whether you need a confirm password field at all is a separate question worth asking.
UX Best Practices
Best practices for special characters in passwords:
- Allow all special characters in passwords, including the space and non-English characters.
- Encourage long passphrases; a symbol is welcome but should not be mandatory.
- Never strip or silently change characters. Escape input on the server so a symbol like
<or'cannot break anything. - If you cannot accept every character yet, list the allowed symbols beside the field before the user starts typing.
- Offer a show password toggle so people can check what they typed.
