Glob Tester

Almost every build tool, test runner, linter and bundler asks for globs: which files to compile, which to ignore, which folders to watch. A pattern that looks right but misses a file, or matches too many, wastes time because the failure is silent. Testing it against a list of real paths shows immediately which ones it picks up.

The syntax

The star matches any run of characters within one path segment, so src/.ts matches files directly in src. The double star, called globstar, matches any number of segments, including none, so src/**/.ts reaches every depth. The question mark matches exactly one character, and square brackets match one character from a set or range, as in [a-c]. Braces list alternatives, so .{ts,tsx} matches both extensions, and extglobs such as !(.min).js and +(a|b) add negation and repetition for the segment. A pattern that starts with ! negates the rest.

Dotfiles

By default a star does not match a name that begins with a dot, so * does not match .env and **/*.yml does not reach .github/workflows/ci.yml, because the folder .github is hidden. This is the behaviour of most glob libraries and of the shell. The option “Match dotfiles” switches it off. With it on, * matches both .env and a.txt; with it off, only a.txt.

Matching on the file name

A pattern without a slash, such as *.md, normally matches only the top level. gitignore and some tools treat it as applying at every depth. The option “Match patterns without / against the file name only” gives that reading: with it on, *.md matches README.md and docs/guide.md, with it off only README.md. Ignore case turns on case-insensitive matching for file systems that do not distinguish case.

The regular expression

Below the results the page prints the regular expression that the pattern became. It is rarely something to write by hand, but it explains surprises: you can see that a single star is [^/]*? and that globstar allows any number of segments. If a pattern behaves unexpectedly, comparing the expression with the paths often shows why.

A worked example

The Sample button loads the pattern src/**/*.{ts,tsx} and eleven paths. Five paths match: src/index.ts, src/App.tsx, src/utils/format.ts, src/utils/format.test.ts and src/components/Button/Button.tsx. Six do not: the .css file in the same folder, the test in tests/e2e, the file in docs, .github/workflows/ci.yml, package.json and README.md. Using the short list src/a.ts, src/x/y/b.tsx, src/c.js and lib/d.ts, the pattern yields true, true, false and false.

Limits

The page tests paths you type against one pattern at a time and does not read a file system. Different programs implement globs slightly differently. Shells, gitignore, minimatch, fast-glob and Python’s pathlib each have their own rules about leading slashes, trailing slashes, negation and dotfiles, so treat a match here as strong evidence and confirm in your tool when it matters. The first 1,000 paths are listed.

Writing patterns that stay readable

A good test list is the best documentation for a pattern. Include a file at the top level, one several folders down, a hidden file, a file with two dots in its name such as a test file, and a path that must not match. If the results are what you expect for all five, the pattern is probably right. Prefer explicit extensions to a bare star, avoid a leading double star unless you really need every folder, and write one negation at a time, since stacked exclusions are the hardest part of a pattern to reason about.

Related tools

• Regex Tester is the tool for full regular expressions.
• Diff Checker compares two lists of files or texts.
• SemVer Calculator tests version ranges, another pattern language used in build files.
• Chmod Calculator builds the permissions of files that your globs select.