Unix File Path Regex
Validates an absolute Unix-style file path such as /home/user/file.txt, rejecting relative paths and double slashes.
Regex Pattern
^/(?:[^/]+/?)*$Pattern Breakdown
Hover over a token to see what it does.
| Token | Meaning |
|---|---|
| ^/ | Anchors to the start of the string and requires the path to begin with a root slash |
| (?: | Opens a non-capturing group for one path segment |
| [^/]+ | Matches one or more characters that are not a slash, i.e. a segment name |
| /? | Matches an optional trailing slash after the segment |
| )* | Repeats the segment group zero or more times to allow any path depth |
| $ | Anchors the match to the end of the string |
Detailed Explanation
What it does
This pattern validates that a string is an absolute Unix path: it must start with a forward slash and consist of zero or more segments, each containing at least one non-slash character, optionally separated by single slashes. The bare root path / is also valid on its own.
Why it works
The leading ^/ enforces an absolute path. Each repetition of the group (?:[^/]+/?)* requires at least one non-slash character before an optional slash, which means two consecutive slashes can never be consumed since there is no way to match zero characters between them, correctly rejecting paths like /home//user.
Common use cases
- Validating file path input in a Linux or macOS command-line tool
- Sanitizing user-supplied paths before use in filesystem operations
- Detecting absolute Unix paths embedded in configuration files or logs
- Distinguishing Unix-style paths from Windows paths in cross-platform code
Edge cases
- The bare root path / is valid because the repeated group can match zero times
- A trailing slash, as in /home/user/, is valid since the optional /? at the end of the last segment allows it
- Consecutive slashes, as in /home//user, are rejected because a segment requires at least one non-slash character
- Relative paths like home/user or ./config are rejected since they do not begin with a leading slash
Limitations
- Does not reject the reserved null byte or verify segment length limits enforced by real filesystems
- Treats any non-slash character as valid within a segment, including characters that are unusual in practice like newlines
- Does not resolve or normalize . and .. segments; it only checks syntactic shape
Interactive Tester
Edit the pattern or text below — matching runs live in your browser.
Test Cases
Editable — add your own inputs to see if they pass.
| Input | Expected | Result | |
|---|---|---|---|
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass |
Language Variants
Production-ready examples in 12 languages.
const unixPathRegex = /^\/(?:[^/]+\/?)*$/;
console.log(unixPathRegex.test('/home/user/file.txt')); // trueCommon Mistakes
Using .* for segments, which allows slashes inside a single segment and defeats path structure validation
Fix: Use [^/]+ so each segment is explicitly bounded by slash characters
Forgetting the leading ^/, allowing relative paths to pass as valid
Fix: Anchor with ^/ so only absolute paths starting at root are accepted
Allowing zero-length segments, which lets malformed paths with double slashes validate successfully
Fix: Require [^/]+ (one or more) rather than [^/]* (zero or more) for each segment
Performance Notes
- The pattern uses only bounded, non-overlapping quantifiers, so it has linear time complexity with no catastrophic backtracking risk
- Because each segment requires at least one character, the engine cannot loop on empty matches within the repeated group
- Anchors at both ends keep the check a full-string match rather than a scan for a substring
Browser Compatibility
| Engine | Supported | Notes |
|---|---|---|
| Chrome | Yes | — |
| Firefox | Yes | — |
| Safari | Yes | — |
| Edge | Yes | — |
| Node.js | Yes | — |