PatternRegex

Match a Windows file path

Match an absolute Windows file path — a drive letter, colon and backslash, then one or more segments that avoid the characters Windows filenames forbid.

Last updated

Patterng
[A-Za-z]:\\(?:[^\\/:*?"<>|\r\n]+\\)*[^\\/:*?"<>|\r\n]*
Open in Regex Tester & Builder

Matches

  • C:\\Users\\ada\\Documents\\report.docx
  • open D:\\Projects\\app\\src\\index.ts now

Doesn’t match

  • /usr/local/bin/app is a unix path
  • just plain text C without a colon

Why it’s written this way

A drive-letter path always starts [A-Za-z]:\\ — a single letter, a colon, then a literal backslash. Each folder segment is a run of characters excluding backslash, forward slash and the characters Windows reserves — : * ? " < > | plus carriage return and newline — followed by another backslash, repeated for however many folders deep the path goes, with a final segment left unterminated for the file name.

Excluding the reserved character set instead of positively listing allowed characters means normal filenames with spaces, dots and parentheses all match without special-casing them.

Edge cases to know

  • →Forward slashes are rejected outright: a mixed-style path like C:/Users/ada does not match at all, even though Windows APIs generally tolerate it. Normalise separators first, or widen the pattern to accept both.
  • →It does not check that the drive letter actually exists or that intermediate segments are valid folder names beyond excluding reserved characters — a segment of just dots or trailing spaces, which Windows itself rejects, still matches here.
  • →UNC paths like \\\\server\\share are a different shape entirely — two leading backslashes instead of a drive letter — and are not covered.

Part by part

[A-Za-z]:
The drive letter and its colon. A single letter, either case, which is what anchors this to a Windows absolute path rather than a relative one.
(?:
Opens the repeated directory group, non-capturing so the repetition does not fill the match array.
)*
Zero or more directory components, which is what lets a bare drive root match as well as a deeply nested path.

Common mistakes

  • [A-Za-z]:\\.*

    A greedy dot swallows the rest of the line, so a sentence mentioning a path takes the trailing prose with it — including the closing quotation mark, which then breaks whatever consumes the match.

  • [A-Za-z]:/(?:[^/]+/)*[^/]*

    Forward slashes are accepted by most Windows APIs but are not what the shell or the file explorer produce, so a pattern written this way misses the paths people actually paste from Windows.

  • [A-Za-z]:\\(?:[^\\]+\\)*[^\\]*

    Excluding only the backslash lets the illegal characters through, so a path containing a colon, an asterisk or a pipe matches — and those are precisely the characters Windows forbids in a filename.

Questions

Why does the pattern exclude so many characters?

Because Windows forbids them in filenames: colon, asterisk, question mark, quotation mark, angle brackets and the pipe. Excluding them is what stops the match running past the end of a real path into surrounding text.

Does it match UNC network paths?

No. Those start with two backslashes and a server name rather than a drive letter, as in the form beginning server then share. They need a separate alternative, since the leading structure is entirely different.

What about paths longer than 260 characters?

The pattern does not care, but Windows historically did. Long paths need the extended-length prefix and opt-in support, so a path that matches here can still fail to open on an older system.

Does it distinguish a file from a directory?

No. The final component is optional and unconstrained, so a trailing directory and a filename look identical to it. Only the filesystem can answer which one exists.

Related in Patterns