UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

Glob Tester

Test glob patterns against newline file/path candidates.

About Glob Tester

Glob patterns are the universal language for matching file paths — from .gitignore rules to webpack config entries, tsconfig include arrays, Docker COPY instructions, shell scripts, and CI pipeline path filters. But glob syntax has subtle differences across implementations and it is easy to write a pattern that matches more or less than intended without a way to test it. Glob Tester lets you write a pattern and paste a list of file paths and see instantly which paths match and which do not, with matches highlighted in real time as you type. Supports the standard glob metacharacters: * for any characters within a single path segment, ** for any path depth, ? for exactly one character, and character classes like [abc] and [!abc]. Whether you are debugging a .gitignore rule that is ignoring too many files, verifying a tsconfig include, or writing a build script path filter, this tool.

Why use Glob Tester

Real-Time Match Highlighting

Every keystroke re-evaluates the entire path list against the current pattern — no submit button, no delay, immediate visual feedback as you refine the glob.

Supports ** Deep Wildcards

Correctly handles the ** multi-segment wildcard used in .gitignore, tsconfig, Bash globstar, and build tools — not just the single-level * most shell tools support.

Handles ? and Character Classes

Supports ? for single-character wildcards and [abc] / [!abc] character classes, covering the full standard glob syntax for precise pattern authoring.

No Shell or Node.js Required

Test glob patterns directly in the browser — no need to create test files, run a shell script, or install a glob library just to validate a pattern.

Works With Any Config Format

Patterns from .gitignore, tsconfig include/exclude, webpack entry globs, Docker .dockerignore, GitHub Actions path filters, and shell scripts all use compatible glob syntax.

Match Count at a Glance

The number of matching and non-matching paths is displayed so you can quickly verify a pattern selects exactly as many files as expected.

How to use Glob Tester

Enter your glob pattern in the pattern input field — for example *.ts, src/**/*.js, or **/__tests__/**.
Paste your list of file paths into the paths panel, one path per line — use relative paths starting without a leading slash for the most accurate matching.
Matching paths are highlighted in green and non-matching paths remain neutral, updating in real time as you modify the pattern or the path list.
Adjust the pattern and observe which paths enter or leave the match set to narrow down the intended selector.
Use the match count shown below the path list to verify you are selecting the expected number of files.
Copy the tested pattern directly into your configuration file, .gitignore, tsconfig.json, webpack entry, or shell script once you are satisfied with the match results.

When to use Glob Tester

When writing a .gitignore rule and you want to verify it ignores exactly the intended files without accidentally excluding tracked source files.
When configuring the include or exclude arrays in tsconfig.json and you need to confirm the TypeScript compiler will see the right set of .ts files.
When writing a webpack entry glob and you want to see exactly which modules will be bundled before running the build.
When authoring a GitHub Actions workflow with path filters (on.push.paths) and you want to verify which file changes will trigger the workflow.
When writing a shell glob in a Makefile or CI script and you need to confirm the pattern expands to the correct set of files without running it on the live filesystem.
When debugging a recursive pattern like **/*.test.ts to see exactly which test files a test runner will pick up from a specific directory tree.

Examples

Match TypeScript source files only

Input: Pattern: src/**/*.ts Paths: src/app.ts src/components/Button.ts src/utils/helpers.ts src/styles/main.css dist/app.js README.md

Output: MATCH: src/app.ts MATCH: src/components/Button.ts MATCH: src/utils/helpers.ts NO MATCH: src/styles/main.css NO MATCH: dist/app.js NO MATCH: README.md 3 of 6 paths matched

Exclude test files with negation insight

Input: Pattern: **/__tests__/** Paths: src/__tests__/app.test.ts src/__tests__/utils.test.ts src/app.ts src/utils/helpers.ts

Output: MATCH: src/__tests__/app.test.ts MATCH: src/__tests__/utils.test.ts NO MATCH: src/app.ts NO MATCH: src/utils/helpers.ts 2 of 4 paths matched

Single-char wildcard for numbered files

Input: Pattern: log-?.txt Paths: log-1.txt log-2.txt log-10.txt error.txt

Output: MATCH: log-1.txt MATCH: log-2.txt NO MATCH: log-10.txt (two chars after dash) NO MATCH: error.txt 2 of 4 paths matched

Tips

Test the inverse of your intended pattern too — paste a set of paths you do NOT want to match and verify none of them are highlighted green, preventing accidental over-matching.
When debugging a tsconfig.json include that is missing files, start with ** and progressively narrow to **/*.ts, then src/**/*.ts, to isolate which segment of the pattern is rejecting the files you expect.
For .gitignore testing, remember that .gitignore interprets a pattern without any / as anchored to any directory depth — prefix with / in .gitignore (not in this tool) to anchor it to the repo root.
Use brace expansion like **/*.{ts,tsx} if your target environment supports it (Node.js glob libraries and most shell implementations do) to match multiple extensions without writing two separate patterns.
Include a few paths that should NOT match alongside the ones that should when building your test list — this guards against accidentally writing an overly broad pattern like ** that matches everything.

Frequently Asked Questions

What is the difference between * and ** in glob patterns?▾

A single * matches any sequence of characters within a single path segment — it will not cross a / separator. So src/*.ts matches src/app.ts but not src/components/Button.ts. A double ** matches across path separators and any number of directory levels, so src/**/*.ts matches both src/app.ts and src/components/Button.ts.

Does the tool match .gitignore semantics exactly?▾

The tool implements standard glob matching as used in minimatch and similar libraries. .gitignore has a few additional rules — for example, a pattern without a / matches at any directory depth, and a leading ! negates a rule — that go beyond basic glob semantics. The tool is ideal for testing the pattern matching part; .gitignore-specific negation and anchoring rules should be verified with 'git check-ignore -v' on the actual repository.

What does ? match?▾

A ? matches exactly one character at that position in the path segment. It does not match / separators. So file?.js matches file1.js and fileA.js but not file10.js and not dir/file1.js.

How do character classes work in globs?▾

[abc] matches any single character that is a, b, or c. [a-z] matches any lowercase letter. [!abc] or [^abc] matches any single character that is NOT a, b, or c. Character classes do not match / separators. Example: src/[abc]*.ts matches src/app.ts and src/base.ts but not src/index.ts.

Should I include a leading slash in my file paths?▾

Use relative paths without a leading slash (e.g. src/app.ts, not /src/app.ts) for most use cases. .gitignore, tsconfig, and webpack all operate on relative paths from the project root. Leading slashes anchor the match differently across implementations — omitting them gives the most predictable results in this tool.

Why does my ** pattern not match the root-level files?▾

** matches zero or more path segments, so **/*.ts should match both root-level .ts files and deeply nested ones. If root files are not matching, check that the pattern does not have an unintended leading directory component. A pattern like src/**/*.ts will only match files inside the src directory, not at the project root.

Can I test multiple glob patterns at once?▾

The tool currently evaluates a single pattern against the full path list. To test multiple patterns, test them individually and compare the match sets, or construct a brace expansion pattern where your implementation supports it (e.g. **/*.{ts,tsx}).

Is the glob implementation the same as Node.js minimatch or Bash globstar?▾

The tool uses a standard glob algorithm consistent with minimatch and micromatch, which are the libraries underlying most JavaScript build tools (webpack, jest, TypeScript, ESLint). Bash globstar behavior is similar but not identical — Bash treats ** differently with respect to hidden files and symlinks in some edge cases.

Explore the category

Glossary

Glob: A pattern language for matching file paths using wildcard characters. The word 'glob' comes from the Unix shell's 'global' command for expanding filename patterns.
** (double star): A glob wildcard that matches any number of path segments including zero, crossing directory boundaries. **/*.ts matches TypeScript files at any depth in the directory tree.
* (single star): A glob wildcard that matches any sequence of characters within a single path segment, not crossing / separators. *.js matches any .js file in the current directory only.
? (question mark): A glob wildcard that matches exactly one character at that position in a path segment, excluding / separators. Useful for matching files with single-character variation.
Character Class: A glob construct enclosed in square brackets that matches any single character from the specified set. [a-z] matches any lowercase letter; [!0-9] matches any character that is not a digit.
minimatch: A popular Node.js library implementing glob matching, used internally by webpack, Jest, TypeScript, and ESLint. The de-facto standard for glob semantics in the JavaScript ecosystem.