Glob Pattern Tester

This tool tests a glob pattern against a list of file paths and shows exactly which ones match, live as you type. It’s useful for sanity-checking .gitignore rules, build globs, CI path filters, and tooling config before you commit them — so you catch a too-greedy or too-narrow pattern early.

How it works

The tester compiles your glob into a regular expression and anchors it to the whole path, so a path matches only when the entire string fits the pattern. Brace alternation is expanded first, then the wildcards are translated:

• * → any run of characters except a slash (stays inside one segment)
• ** → the globstar, matching across directory boundaries
• ? → exactly one character
• [a-z], [!abc] → character classes, including negation
• {ts,tsx} → alternation, expanded to ts or tsx

Each path you paste is tested against the compiled expression and ticked if it matches, with a running count of matches.

Example

Pattern: src/**/*.{ts,tsx}

The globstar ** reaches files at any depth under src, while the {ts,tsx} alternation accepts both extensions.

Common patterns and what they match

CI path filters (GitHub Actions)

GitHub Actions supports glob patterns in paths: filters to run a workflow only when relevant files change. Testing them before committing is valuable because a misconfigured path filter silently skips CI on relevant changes — or triggers it unnecessarily on every push.

on:
  push:
    paths:
      - "src/**"        # any change under src/ at any depth
      - "package.json"  # dependency changes
      - "!**/*.md"      # exclude markdown (negation)

Paste the paths: patterns one by one into this tester with representative file paths to confirm the filter behaves as expected.

gitignore patterns

.gitignore patterns use their own slightly different glob rules — ** works the same, but .gitignore patterns are not anchored to the repository root unless they start with /. This tester shows shell-style anchored matching, which is most useful for catching overly broad patterns.

For example, *.log in a .gitignore matches any .log file at any depth (gitignore semantics), but as a shell glob it only matches .log files in the current directory. Use this tool to reason about the pattern’s intent, then verify in git if exact gitignore behaviour matters.

Build tool globs

Bundlers like Vite, webpack, and Rollup use glob patterns for entry points and file discovery. TypeScript’s tsconfig.json uses include/exclude arrays of globs. Testing patterns like **/__tests__/**/*.test.ts or !**/node_modules/** before adding them to config avoids hard-to-debug build errors.

Tips for writing reliable glob patterns

• Prefer explicit over permissive. src/**/*.ts is safer than **/*.ts — the latter matches TypeScript files anywhere in the repository, including in node_modules if it is somehow in scope.
• Test the empty-match case. If a CI path filter accidentally matches no files in your test set, the workflow may never trigger.
• Negation order matters. In tools that support negation (starting with !), negation patterns are evaluated in order — later patterns override earlier ones.
• Forward slashes are universal. Even on Windows, glob patterns in most tools use / as the path separator.

Everything is compiled and matched in your browser — nothing is uploaded.