Skip to content
Pattern toolkit

Compile glob to regex: gitignore, npmignore, dockerignore

Test glob patterns against a list of paths. Syntax compatible with .gitignore, .npmignore and .dockerignore: * (any non-slash), ** (any including slash), ? (single char), [abc] (char set), [!abc] (negated set), {a,b,c} (alternation). Each line of the list is tested and color-coded match/no-match. Also displays the regex equivalent compiled from the glob, copyable and reusable in shell scripts, Python or JavaScript. For full regex power, see the dedicated regex tester.

How to test a glob pattern

  1. 1

    Enter the pattern

    Typical syntax: **/*.js (all.js even nested), src/**/*.{ts,tsx} (all TypeScript inside src), **/node_modules/** (everything under node_modules at any level), logs/[!.]* (files in logs except dotfiles).

  2. 2

    Paste the path list

    One path per line. Typically the output of find. -type f or git ls-files. Relative or absolute paths, slash or backslash; the tester normalizes separators.

  3. 3

    'Test' button

    Match and no-match color-coded: green = match (will be included/excluded), gray = no-match. Top stats: total, match count, no-match count. Compiled regex visible below, useful to copy into bash scripts with =~ or JS with RegExp.

  4. 4

    Iterate until coverage

    Edit pattern, retest. Typical flow: start with a restrictive pattern, broaden until all desired files match. For .gitignore hardcode the paths you do NOT want to commit and verify the desired files fall outside.

Why a dedicated tester

The.gitignore problem. Syntax similar but not identical to shell glob: patterns without slash match at any depth (*.log matches logs/foo.log); patterns with slash are path-relative; ** has specific semantics (cross-directory match). Common mistakes: foo/ includes only directories, !foo negates previous patterns. The tester helps understand why a file gets committed (or doesn't). Note: this tool implements the minimatch / shell glob subset, NOT all the special.gitignore rules (e.g. negation chains).

The minimatch problem. JS bundle ~10KB, but 90% of use cases use only the 5-6 base metacharacters (*, **, ?, [], {}). Here the glob goes through picomatch, the engine behind many Node tools, loaded on this page only: it covers the edge cases too (extglob: !(foo|bar), ?(...), +(...)).

Compile to regex. The tester converts the glob to a regex and tests with RegExp.test(). The regex is visible, copyable, reusable in code (Python re.match, JS /.../.test()). Useful for debugging complex patterns: if the glob matches strangely, read the compiled regex and spot the error.

Supported syntax

*
Match any sequence of NON-slash characters. E.g. *.js matches foo.js but not src/foo.js.
**
Match any sequence including slashes. E.g. src/**/*.js matches src/foo.js, src/utils/helper.js, src/a/b/c/x.js.
?
Match a single non-slash character. E.g. file?.txt matches file1.txt, fileA.txt but not file12.txt.
[abc]
Match a single character among a, b, c. Range supported: [a-z], [0-9], [A-Za-z0-9].
[!abc] or [^abc]
Match a single character NOT among a, b, c. Useful negation for [!.]* = no dotfile.
{a,b,c}
Match one of the alternatives. E.g. *.{js,ts,tsx} matches files with those extensions.
Literals
All other characters (letters, numbers, slash, dot) are literals. To match a literal * or ? use a backslash: \*.txt.

Glossary

Technical terms used on this page, briefly explained.

Glob #
Simplified pattern matching language for file paths, originating from Unix shell. Regex subset with directory-specific metacharacters (*, **) and file metacharacters (?, [], {}).
minimatch #
JavaScript library (Isaac Z. Schlueter, npm author) for glob matching, dependency of npm/yarn/eslint/jest. ~700 lines, supports extended extglob, ~10KB minified.
extglob #
Bash 4+ extension with patterns !(foo), ?(foo), +(foo), *(foo), @(foo). Not supported by this tester (rare use case).
.gitignore #
File with glob rules that tell git which files NOT to track. Syntax similar to shell glob but with specific rules: ! for negation, / path-anchor, ** for cross-directory match.
Path normalization #
Path separator conversion: Windows \ -> /. Backslash paths are normalized before matching. Trailing slash ignored.
Brace expansion #
Syntax {a,b,c} that expands into 3 alternatives. Not regex (regex uses (a|b|c)). The compiled glob expands into a regex group with OR.

Frequently asked questions

Is the tester 100% compatible with minimatch?
Nearly. Implements * ** ? [] [!] {}, ranges, extglob (!(), ?(), +(), *(), @()), backslash escapes and a leading ! negation (the result is inverted). The engine is picomatch, with dotfiles included. Not exposed: the nocase and noglobstar options.
Can I test.gitignore patterns?
Yes, with .gitignore semantics on: a pattern without a slash applies at any depth (*.log takes logs/foo.log), build/ takes the folder and everything in it, /root.txt is anchored to the root, ! inverts. The tool tests one pattern at a time: for precedence across the lines of a .gitignore file use git check-ignore -v file/path.
Do paths with spaces work?
Yes, the tool treats every line as a literal path. Spaces in paths are normal characters. No need for quoting/escape.
Is matching case-sensitive?
Yes, always. For case-insensitive, normalize the list first (e.g. all lowercase) and use a lowercase pattern. There is no compile flag here.
How do I test that a pattern does NOT match?
Add to the list the paths you want to exclude and verify they show as 'No match'. For inverse testing (match paths the pattern should NOT capture): hand-built complementary pattern, union pattern ({a,b,c}), or switch to regex tester.
The pattern is compiled to regex: can I copy it?
Yes, the regex appears below the result list. It is a JavaScript regex: it also works in PHP preg_match and Python re, but it uses lookaheads, so it is not suitable for bash =~, which only takes POSIX extended regexes.
Line limit in the list?
Technically none, but for lists >10000 paths the render becomes slow. For very large datasets: filter the list first (e.g. only files of interest) or use find... | grep -E '' from terminal.

Who builds these tools?

Maurizio Fonte, senior IT consultant with 20+ years in PHP, Laravel, unmanaged Linux infrastructure, applied cybersecurity and AI/LLM integration. Production backends, legacy code modernization, security audits, custom AI agents and MCP servers: the work behind every tool published here.

About Maurizio Fonte