What Symbols Can Be Used in Passwords?

Passwords are meant to protect your accounts, devices, or data. Part of making a strong password is using a variety of characters — not just letters and numbers, but also symbols. But exactly *which* symbols are allowed, and are there any you should avoid? In this guide, we’ll cover:

• What “symbols” means in password contexts
• Common allowed symbol sets (ASCII, Unicode, etc.)
• Restrictions websites/services often impose
• Which symbols can cause problems
• Best practices when choosing symbols in passwords

What Counts as a Symbol?

When people refer to “symbols” in passwords, they usually mean:

• Punctuation marks (e.g. period, comma, semicolon)
• Special characters not alphanumeric (e.g. #, @, %, &, *, etc.)
• Sometimes whitespace (spaces) or non-printing characters
• In some systems, even broader Unicode characters (emojis, accented letters, symbols beyond standard ASCII) are accepted

Common Symbol Sets Allowed

Here are some typical sets of symbols accepted by many password systems, especially those following security guidelines.

ASCII Printable Symbols

“Printable ASCII” refers to characters between codes 33 and 126 in the ASCII table (decimal). This excludes control characters. Examples include:

• !
• @
• #
• $
• %
• ^
• &
• *
• ( )
• _ – + =
• { } [ ]
• | \\
• : ; “ ” ’ ‘
• , < . > / ? ~ ` etc.

Whitespace (Spaces)

Some systems allow space characters. Spaces can add entropy and help with memorability, especially when building passphrases. But many systems don’t allow spaces, or trim them, or disallow leading/trailing spaces.

Unicode / Non-ASCII Symbols

More advanced systems may accept non-ASCII symbols: accented letters (á, ü, ñ, etc.), symbols from other scripts, emojis, etc. This expands the possible symbol set significantly. But there are pitfalls (compatibility, normalization, input issues). Many systems restrict to ASCII precisely to avoid these issues.

What Restrictions Are Common?

Because different websites, systems, or devices have different security policies and technical limitations, there are some common restrictions you may encounter:

• Disallowed characters: Some symbols may be disallowed either because they conflict with SQL, HTML, shell scripts, or because they are problematic for encoding. For example: quotes, backslashes, angle brackets, null character (U+0000) etc.
• Password length limits: Some systems set both minimum and maximum lengths. If you use many symbols, you might hit maximum length.
• No leading/trailing whitespace: Spaces at the start or end are often trimmed or rejected.
• Normalization issues: Unicode characters may have multiple representations (combining accents, different code points) which can lead to mismatches. So some systems avoid them.
• Keyboard/locale / mobile input limits: On some keyboards or devices, entering certain symbols is hard or impossible. Services may restrict symbol choices to those likely usable everywhere.
• Disallowed routines for security reasons: Very often, certain simple patterns even with symbols are disallowed: dictionary words with simple symbol substitutions, repeated sequences, etc. These are not exactly symbol restrictions, but relate to how the password is evaluated.

Which Symbols Can Cause Problems?

Even when a system allows many kinds of symbols, there are some that may lead to usability or security problems:

• Quotes and apostrophes (single ′, double ″, backticks) — because of how input strings are parsed, or SQL/command injection concerns.
• Backslashes, forward slashes, pipes (“|”), angle brackets (“<” or “>”)** — they may have special meaning in HTML, URLs, file paths, or scripting contexts.
• Spaces — leading/trailing spaces often trimmed or ignored; zero-width spaces or unusual whitespace characters can be problematic.
• Non-printing/control characters (tabs, newlines, null character) — these often get stripped, normalized, or rejected. They can cause storage/hashing issues.
• Very unusual Unicode symbols or emojis — while strong in terms of entropy, compatibility issues arise: typing them correctly on different devices, normalization, potential mismatches. Also some systems limit to ASCII only.