Filenames are identifiers shaped by operating systems, filesystems, and applications, and each environment defines valid filename characters through allowed sets, reserved symbols, and length/path rules. This guide explains the character rules across Windows, macOS, and Linux, highlights reserved characters to avoid, and outlines practical naming conventions that improve compatibility and reduce errors. You will find concrete examples, platform-specific details, and recommendations to help you choose safe filenames for documents, code, media, and archival projects.
What Makes a Filename Valid
A valid filename must conform to the combined constraints of its operating system, filesystem, and any applications that access it. Validity is determined by allowed character sets, reserved names and symbols, path length limits, and rules around case sensitivity and normalization. While many characters are broadly safe across platforms, some are restricted because they serve control, formatting, or structural roles such as path separators or device identifiers.
In practice, a filename that is technically valid on one system may cause issues when transferred, shared, or referenced in scripts and automation. Understanding the distinctions between allowed characters, discouraged characters, and best practices helps ensure predictable behavior, reliable automation, and smooth collaboration.
Character Categories Across Operating Systems
Broadly, characters used in filenames fall into functional groups: alphanumeric characters that are nearly always safe, punctuation and spacing characters that are conditionally allowed, and reserved symbols that often carry special meaning or are outright prohibited. The following categories provide a practical mental model for evaluating valid filename characters.
Alphanumeric and Symbols That Are Generally Safe
Letters (A–Z, a–z), decimal digits (0–9), and a handful of symbols are widely accepted by most filesystems and applications. These include the hyphen-minus, underscore, period, and a few others when used with awareness of context. They are typically safe in most combinations, though length and position rules may still apply.
The safest approach is to treat alphanumeric ASCII characters as universally supported, and limit the use of punctuation to those with long track records of cross-platform compatibility. Non-ASCII Unicode characters can work on modern systems but may introduce compatibility issues in legacy tools or command-line environments.
Punctuation and Space Characters
Many punctuation marks and space-like characters are allowed by filesystems but can interfere with parsing in scripts, command-line tools, and URLs. Examples include commas, semicolons, brackets, slashes, and various quotation marks. Spaces are permitted by most desktop environments and modern tools, but they require careful handling in scripts and terminal commands.
While these characters are sometimes valid, they increase the risk of misinterpretation, word splitting, and shell metacharacter conflicts. When portability and automation are priorities, it is often better to substitute safer alternatives such as hyphens or underscores.
Platform-Specific Rules and Conventions
Windows, macOS, and Linux each implement distinct rules for valid filename characters, based on their underlying filesystems and historical design decisions. Command-line tools, automation scripts, and cross-platform workflows must account for these differences to ensure reliable behavior across environments.
Windows: Reserved Symbols and Filesystem Limits
Windows reserves a set of characters and names that cannot be used in filenames. These include control characters along with symbols used as namespace separators and device identifiers. The most well-known reserved symbols are the backslash, forward slash, colon, asterisk, question mark, double quote, less-than, greater-than, and vertical bar. The reserved device names like CON, PRN, AUX, NUL, and COM1–COM9, along with their extensions, are also prohibited regardless of extension.
Filenames are limited to 255 characters in most modern filesystems such as NTFS and exFAT, and paths up to 260 characters by default unless extended-length paths are enabled. The use of trailing dots or spaces can also be normalized or stripped by applications, leading to confusion. The following table summarizes key Windows filename constraints.
| Attribute | Verified Detail | Source Type |
|---|---|---|
| Reserved Characters < > : " / \ | ? * | Prohibited in filenames | Microsoft documentation |
| Reserved Device Names CON, PRN, AUX, NUL, COM1–9, LPT1–9 | Cannot be used as filenames | Microsoft documentation |
| Maximum Filename Length | 255 characters | NTFS/exFAT specifications |
| Restricted Characters ASCII 0–31 and 127 (control characters) | Not allowed | Windows API behavior |
| Trailing Periods and Spaces | Often normalized or stripped | Windows file manager behavior |
macOS and Linux: Unix–POSIX Rules and Filesystem Nuances
macOS and Linux generally follow Unix–POSIX rules, where the only forbidden character in a filename is the null byte, and many systems also prohibit the forward slash (/) since it serves as a path separator. Leading dots indicate hidden files, and the period character at the end of a filename may be trimmed by some applications. Different filesystems, such as APFS, HFS+, ext4, and XFS, may impose additional limits or normalization rules.
While modern desktop environments support Unicode and a wide range of characters, practical concerns arise with command-line usage, backup tools, and cross-platform transfers. The following table summarizes common character behavior on Unix-like systems.
| Attribute | Verified Detail | Source Type |
|---|---|---|
| Forbidden Character | Forward slash / (path separator) and null byte | POSIX standard |
| Hidden Files Convention | Names starting with a dot | Unix filesystem convention |
| Trailing Periods and Spaces | Often trimmed by applications and shells | Tooling behavior |
| Recommended Safe Characters | Alphanumerics, hyphen, underscore, period | Cross-platform best practice |
| Length Limits | Filesystem-dependent, often large but practical limits apply | Filesystem documentation |
Practical Naming Conventions and Recommendations
Following consistent conventions reduces edge cases and makes filenames easier to share, automate, and maintain. Favor concise, descriptive names that retain meaning without relying on special characters. Standardizing on a limited set of punctuation improves portability across platforms and simplifies scripting, logging, and user experience.
Recommended Characters and Patterns
- Use letters A–Z and a–z for readability across locales.
- Include decimal digits (0–9) for versioning or ordering.
- Use hyphens to separate words in readable slugs.
- Use underscores when the target environment or tool prefers them.
- Include periods only to separate base names from extensions.
- Avoid leading or trailing spaces, dots, and dashes where possible.
Pitfalls to Avoid
- Avoid spaces; if used, prefer hyphens or underscores.
- Avoid shell metacharacters such as $, *, ?, [, ], (, ), {, }, and backticks.
- Avoid commas, semicolons, and other punctuation used in scripts or URLs.
- Avoid Unicode symbols unless you control the toolchain and encoding.
- Do not use leading dots for non-hidden files to prevent accidental concealment.
- Steer clear of reserved device names on Windows.
Implications for Version Control, URLs, and Automation
Filenames are used in many contexts beyond local filesystems, including version control, URLs, APIs, and build systems. Safe filenames reduce complexity and increase reliability, while problematic characters can cause parsing failures, broken references, or platform-specific issues.
In URLs, prefer percent-encoding for reserved characters, and minimize case sensitivity surprises by using lowercase. In version control, consistent naming conventions improve blame, history readability, and merge reliability. For automation, stick to a constrained character set to avoid fragile scripts that depend on complex quoting or escaping.
Cross-Platform Compatibility Checklist
When sharing files across Windows, macOS, and Linux, or when filenames may be used in automated pipelines, consider applying a compatibility checklist. This helps prevent hard-to-diagnose failures caused by otherwise valid but risky characters.
The following quick checklist summarizes what to favor or avoid for maximum cross-platform safety.
- Favor ASCII alphanumerics plus hyphen and underscore.
- Favor hyphens over spaces or underscores for word separation.
- Avoid leading/trailing dots and spaces.
- Avoid reserved device names on Windows.
- Avoid shell metacharacters and path separators.
- Prefer lowercase to reduce case-sensitivity issues.
Legacy Systems and Future-Proofing
Older systems and specialized tools may impose stricter limits than modern operating systems, and long paths or complex names can break workflows that assume simple names. While current desktop environments are permissive, planning for legacy compatibility ensures smooth archival and migration. Adopting conservative naming rules today reduces friction in the future.