Glob Pattern Tester
NewTest a glob pattern against a list of sample file paths to see exactly which ones match, supporting *, **, ?, character classes, and brace alternation.
Matches
Supports the common glob tokens: * (any characters except a path separator), ** (any characters including across directories), ? (exactly one character), [abc] (a character class), and {a,b,c} (alternation between options) — the same syntax used by .gitignore, most bundler config "include" patterns, and shell globbing.
Frequently Asked Questions
What glob syntax does this tool support?
`*` for any characters except a path separator, `**` for matching across directory boundaries, `?` for exactly one character, `[abc]` character classes, and `{a,b,c}` brace alternation — the same core glob tokens used by `.gitignore`, most bundler "include"/"exclude" config, and shell globbing.
What is the difference between * and ** in a glob pattern?
A single `*` matches any run of characters but stops at a `/` path separator, so it only matches within one directory level, while `**` matches across any number of directory levels, which is why patterns like `src/**/*.ts` are needed to match files nested arbitrarily deep.
Can I test multiple file paths against the same pattern at once?
Yes — paste as many sample paths as you like into the paths box, one per line, and every path is checked against the current pattern simultaneously, with a checkmark or cross shown next to each.
Does this exactly match tools like fast-glob, minimatch, or .gitignore?
It implements the common core glob syntax those tools share, but doesn't replicate every edge case or extension-specific behavior (like `.gitignore`'s special leading-slash and directory-only trailing-slash rules), so always double-check unusual edge cases against your actual tool's documentation.
Why would I need a glob pattern tester?
Glob patterns in build configs, `.gitignore` files, and CI workflows are notoriously easy to get subtly wrong — testing a pattern against real sample paths before committing it to a config file catches mistakes immediately instead of discovering them when a build silently includes or excludes the wrong files.