Glob Pattern Tester

What this tool does

Glob Pattern Tester checks a glob pattern, the kind used in .gitignore files, webpack/build tool configs, and shell globbing, against a list of sample paths using minimatch (the same engine npm, ESLint and webpack use internally), showing exactly which paths match.

Glob patterns look deceptively like regular expressions but follow their own distinct rules, * matches within one path segment, ** matches across any number of segments, and {a,b} expands to multiple alternatives, rules that are easy to get subtly wrong when writing a .gitignore entry or a build tool’s include/exclude config.

This tester checks any glob pattern against a list of sample file paths using minimatch, the exact engine npm, ESLint, webpack and many other Node.js tools use internally, so a pattern confirmed working here behaves identically in those real tools.

How to use Glob Pattern Tester

1. Enter the Glob pattern you want to test.
2. Adjust Match dotfiles and Case-insensitive as needed for your use case.
3. Paste or edit the Sample paths, one per line.
4. Review which paths are marked as a match.

Tips for better results

• ** matches across any number of path segments (including zero), while a single * only matches within one segment, this distinction is the single most common source of unexpected glob behaviour.
• Dotfiles (paths with a segment starting with a dot, like .env or .git/config) are excluded from * and ** matches by default in most glob implementations; toggle Match dotfiles on if you need patterns to match them too.
• {a,b,c} brace expansion matches any one of the listed alternatives, useful for something like *.{ts,tsx} to match either extension in one pattern.
• This is the exact same matching engine (minimatch) that powers .gitignore-style patterns in many JavaScript build tools, so testing here reliably predicts real tool behaviour, even though .gitignore itself uses a very similar but not 100% identical rule set.

Common use cases

• Debugging why a webpack, ESLint or other build tool config’s include/exclude glob isn’t matching the files you expect.
• Testing a .gitignore-style pattern against a list of real file paths before committing it.
• Understanding the difference between * and ** matching behaviour with concrete examples.
• Verifying a file path pattern before using it in a script or automation.

Common mistakes to avoid

• Using a single * where ** was needed (or vice versa), the most common source of a glob matching too narrowly or too broadly across directory levels.
• Forgetting that dotfiles are excluded by default; a pattern like *.ts won’t match .config.ts unless Match dotfiles is explicitly enabled.
• Assuming this exactly replicates .gitignore’s own matching rules in every detail; while very close (and useful for predicting behaviour), .gitignore has a few of its own special-case rules not covered by generic glob matching.