/^/
MediumFiles5 min read

Windows File Path Regex

Validates an absolute Windows file path such as C:\Users\name\file.txt, requiring a drive letter and rejecting reserved filename characters.

#windows-path#file-path#files#validation#filesystem

Regex Pattern

^[a-zA-Z]:\\(?:[^\\/:*?"<>|\r\n]+\\)*[^\\/:*?"<>|\r\n]*$

Pattern Breakdown

Hover over a token to see what it does.

^[a-zA-Z]:\\(?:[^\\/:*?"<>|\r\n]+\\)*[^\\/:*?"<>|\r\n]*$
TokenMeaning
^Anchors the match to the start of the string
[a-zA-Z]:Matches a single drive letter followed by a colon, e.g. C:
\\Matches one literal backslash path separator
(?:Opens a non-capturing group for a repeatable path segment
[^Begins a negated character class excluding reserved characters
:*?Excludes the reserved Windows filename characters colon, asterisk, and question mark
)*Repeats the segment-plus-backslash group zero or more times
$Anchors the match to the end of the string

Detailed Explanation

What it does

This pattern validates absolute Windows paths that start with a drive letter and colon, followed by zero or more backslash-separated directory segments and an optional final file or folder name. It rejects characters that Windows forbids in file and folder names, such as : * ? " < > | and control characters.

Why it works

The drive prefix [a-zA-Z]: matches exactly one letter followed by a colon, then a literal backslash. The body is built from a repeating non-capturing group (?:[^\\/:*?"<>|\r\n]+\\)* that consumes a directory name followed by its trailing backslash, repeated for every intermediate folder. The final segment is matched separately by the same negated character class without a trailing backslash requirement, allowing the path to end in either a filename or a bare trailing backslash.

Common use cases

  • Validating a file path entered into a desktop application on Windows
  • Sanitizing user-supplied paths before passing them to filesystem APIs
  • Detecting Windows-style paths embedded in log files or configuration exports
  • Distinguishing Windows paths from Unix paths in cross-platform tooling

Edge cases

  • A bare drive root like C:\ is valid because the trailing segment can match zero characters
  • Paths with spaces, such as C:\Program Files\App\app.exe, are valid since space is not in the excluded character set
  • Forward-slash paths like C:/Users/name are rejected because the separator must be a literal backslash
  • Relative paths without a drive letter, like folder\file.txt, are rejected since the pattern requires the drive prefix

Limitations

  • Does not validate UNC network paths such as \\server\share\file.txt
  • Does not enforce the 260-character MAX_PATH limit or reserved device names like CON or NUL
  • Does not verify the path actually exists on disk, only that it is syntactically well-formed

Interactive Tester

Edit the pattern or text below — matching runs live in your browser.

//
Open in Playground →
C:\Users\name\file.txt C:\ D:\folder\subfolder\

Test Cases

Editable — add your own inputs to see if they pass.

InputExpectedResult
Pass
Pass
Pass
Pass
Pass
Pass
Pass
Pass

Language Variants

Production-ready examples in 12 languages.

const winPathRegex = /^[a-zA-Z]:\\(?:[^\\/:*?"<>|\r\n]+\\)*[^\\/:*?"<>|\r\n]*$/;
console.log(winPathRegex.test('C:\\Users\\name\\file.txt')); // true

Common Mistakes

Forgetting to double-escape backslashes in the source pattern, resulting in a regex that only matches a single slash instead of the Windows path separator

Fix: Use \\\\ in most language string literals (or a raw/verbatim string like @"..." in C# or r"..." in Python) to represent one literal backslash

Using a forward slash / as the separator, rejecting genuine Windows paths

Fix: Match backslash \\ as the separator; forward slashes are a Unix convention, though Windows APIs often accept both

Allowing any character in path segments, which lets through reserved characters like : or | that Windows filenames cannot contain

Fix: Use a negated character class [^\\/:*?"<>|\r\n] to explicitly exclude reserved characters

Performance Notes

  • The repeated group (?:[^\\...]+\\)* is linear in the number of path segments and does not backtrack catastrophically because each segment requires at least one character before its separator
  • Anchoring with ^ and $ avoids matching a valid-looking path fragment inside a longer invalid string
  • For very long paths, precompiling the regex once and reusing it avoids recompilation overhead on repeated validation calls

Browser Compatibility

EngineSupportedNotes
ChromeYes—
FirefoxYes—
SafariYes—
EdgeYes—
Node.jsYes—