Glob Pattern Tester: Test File Matching Patterns Online (Free Tool)

Paste a glob pattern and a list of file paths into the free Glob Pattern Tester on FindUtils, and see which files match instantly. The tool highlights matched and unmatched paths in real time, supports all standard glob syntax including *, **, ?, [abc], {a,b}, and ! negation, and runs entirely in your browser — no files are uploaded, no data leaves your machine.

Glob patterns are the backbone of file matching across developer tooling. They power .gitignore files, webpack configurations, CI/CD pipeline definitions, linting rules, and shell commands. Getting a pattern wrong can mean accidentally ignoring critical files, building the wrong assets, or exposing sensitive data. Testing patterns before deploying them saves hours of debugging.

What Are Glob Patterns

A glob pattern is a string that uses wildcard characters to match file and directory names. Unlike regular expressions, globs are designed specifically for path matching. They originated in Unix shells in the 1970s and are now embedded in virtually every build tool, version control system, and package manager.

Common places where glob patterns appear:

• .gitignore — Exclude files from version control
• Webpack / Vite — Define entry points and asset includes
• ESLint / Prettier — Target files for linting and formatting
• GitHub Actions / CI pipelines — Trigger builds on specific file changes
• Docker .dockerignore — Exclude files from build context
• VS Code settings.json — Hide files in the explorer, configure search scope

How to Use the Glob Pattern Tester (Step by Step)

Step 1: Open the Tool

Navigate to FindUtils' Glob Pattern Tester. You will see two input areas: one for your glob pattern and one for a list of file paths to test against. The interface works on desktop and mobile.

Step 2: Enter Your Glob Pattern

Type your glob pattern in the pattern input field. For example, enter **/*.ts to match all TypeScript files at any depth. The tool supports standard glob syntax: single star, double star (globstar), question mark, character classes, brace expansion, and negation.

Step 3: Add File Paths

Enter file paths to test against, one per line. You can type them manually, paste from a terminal's find or ls output, or paste a directory listing from your IDE. For example:

src/index.ts
src/utils/helpers.ts
src/components/Button.tsx
src/styles/main.css
package.json
README.md

Step 4: Review Matches in Real Time

As you type or edit the pattern, the tool highlights matching paths instantly. Matched files are visually distinguished from unmatched ones, so you can confirm your pattern selects exactly the files you intended — no more, no less.

Step 5: Iterate and Refine

Adjust your pattern and see results update immediately. This rapid feedback loop is what makes an online glob tester far more efficient than testing patterns by running shell commands or pushing config changes to see what CI picks up.

Complete Glob Syntax Reference

The following table covers all glob pattern operators supported by the FindUtils Glob Pattern Tester.

Key Rules to Remember

* never crosses directory boundaries. The pattern *.js matches app.js but not src/app.js. Use **/*.js to match at any depth.

** must appear as a complete path segment. Valid: src/**/test.js. The globstar ** matches zero or more directories between src and test.js.

Brace expansion happens before matching. The pattern {src,lib}/**/*.ts expands to two patterns: src/**/*.ts and lib/**/*.ts.

Character classes are single-character. [abc] matches one character. For multi-character alternation, use brace expansion: {abc,def}.

Practical Examples

.gitignore Patterns

Test these patterns with a realistic file list in the Glob Pattern Tester:

# Dependencies
node_modules/
vendor/

# Build output
dist/**
build/**

# Environment files
.env
.env.*
!.env.example

# OS files
.DS_Store
Thumbs.db

# Logs
*.log
logs/**

The !.env.example negation ensures the example environment file remains tracked while all other .env variants are ignored. This is a pattern developers frequently get wrong — test it before committing.

Webpack and Vite Entry Points

src/**/*.{js,jsx,ts,tsx}

This matches all JavaScript and TypeScript source files, including JSX and TSX variants, at any depth under src/. It will not match CSS, JSON, or other file types.

CI/CD Path Filters (GitHub Actions)

on:
  push:
    paths:
      - 'src/**'
      - 'package.json'
      - '!src/**/*.test.ts'

This triggers the workflow when any file under src/ changes, or when package.json is modified, but not when only test files change. Testing these patterns before pushing avoids wasted CI minutes and missed builds.

ESLint and Prettier Configurations

**/*.{js,jsx,ts,tsx}
!**/node_modules/**
!**/dist/**
!**/*.min.js

Target all source code files while excluding dependencies, build output, and minified bundles. Use the Glob Pattern Tester to confirm your patterns exclude exactly what you intend.

Docker .dockerignore

node_modules
.git
*.md
!README.md
docker-compose*.yml
.env*

A tighter .dockerignore reduces Docker build context size, speeding up image builds. Test patterns to make sure you are not accidentally including secrets or large directories.

Glob vs Regex: When to Use Which

Developers often wonder whether to use a glob pattern or a regular expression. They solve different problems.

Rule of thumb: Use globs for file path matching. Use regex for text content matching. If your tool accepts glob patterns (like .gitignore or webpack config), don't convert to regex — stick with globs. They are simpler, more readable, and purpose-built for the task.

If you need to convert between the two formats, the FindUtils Regex Tester can help you verify the equivalent regular expression.

FindUtils vs Other Glob Testers

FindUtils processes everything in your browser. No file paths are sent to any server, making it safe to test patterns that include internal project structures, proprietary directory names, or paths containing sensitive information.

Common Mistakes and How to Avoid Them

Forgetting ** for recursive matching. Writing *.js when you mean **/*.js is the most common glob mistake. The single * only matches files in the current directory.

Misusing negation order. In .gitignore, order matters. A negation pattern (!file) must come after the pattern that excluded it. If you write !important.log before *.log, the negation has no effect.

Confusing glob with regex. Writing \.js$ in a .gitignore will not work. Globs don't use backslash escapes or anchors the way regex does. Use *.js instead.

Forgetting brace expansion is not regex alternation. In regex, (js|ts) uses parentheses and pipe. In globs, {js,ts} uses braces and comma. Mixing the two causes silent failures.

Not testing with realistic paths. A pattern that works with src/app.js might fail with src/features/auth/login.controller.ts. Always test with your actual project structure. Copy the output of find . -type f into the tester.

Integrating Glob Testing Into Your Workflow

Before committing .gitignore changes: Paste your updated patterns and your project's file tree into the Glob Pattern Tester. Confirm that sensitive files like .env are excluded and necessary files like .env.example are included.

Before updating CI/CD path filters: Test your paths and paths-ignore patterns against recent commits. A wrong glob can cause builds to trigger on every push or, worse, never trigger at all.

When reviewing pull requests: If a PR modifies .gitignore, .dockerignore, or build tool configs with glob patterns, paste them into the tester to verify correctness. This takes 30 seconds and prevents production issues.

During code reviews involving the Diff Checker: When comparing configuration files, paste changed glob patterns into the tester to verify that the diff does not introduce unintended file inclusion or exclusion.

FAQ

Q1: What is a glob pattern? A: A glob pattern is a string containing wildcard characters (*, ?, [...], {...}) used to match file and directory names. Globs are simpler than regular expressions and are specifically designed for file path matching. They are used in .gitignore, shell commands, build tools, and CI/CD configurations.

Q2: What is the difference between * and ** in glob patterns? A: The single * matches any characters within a single directory level — it does not cross the / separator. The double ** (globstar) matches across directory boundaries, including zero or more nested directories. For example, *.js matches app.js but not src/app.js, while **/*.js matches both.

Q3: Can I test .gitignore patterns with this tool? A: Yes. The FindUtils Glob Pattern Tester uses the same pattern matching logic that .gitignore relies on. Paste your .gitignore patterns and your project's file list to see exactly which files would be ignored. Test negation patterns like !.env.example to confirm they work as expected.

Q4: Is my data safe when testing glob patterns online? A: On findutils.com, all processing happens in your browser using JavaScript. No file paths, patterns, or project structures are sent to any server. You can safely test patterns containing internal project names, proprietary directory structures, or paths that hint at sensitive configurations.

Q5: How do I match multiple file extensions with a glob pattern? A: Use brace expansion: **/*.{js,ts,jsx,tsx}. This matches all files ending in .js, .ts, .jsx, or .tsx at any depth. You can also chain multiple patterns on separate lines in .gitignore or similar configs.

Q6: Why does my glob pattern work in the terminal but not in .gitignore? A: Terminal shells (bash, zsh) and .gitignore interpret globs slightly differently. In particular, .gitignore treats patterns without a / as matching in any directory, while shell globs default to the current directory. Additionally, .gitignore uses ! for negation, which needs escaping in some shells. Test both contexts to be sure.

Q7: Can I use glob patterns to filter paths in my JSON configuration files? A: Yes, many tools accept globs in JSON config files. For example, TypeScript's tsconfig.json uses include and exclude arrays with glob patterns. You can also query JSON configurations using the JSON Path Finder and validate structure with the JSON Formatter.

Tools Used

• Glob Pattern Tester — Test glob patterns against file lists in real time
• Regex Tester — Test regular expressions when glob syntax is not enough
• Diff Checker — Compare configuration files side by side to spot glob pattern changes
• JSON Path Finder — Query JSON config files that contain glob pattern settings
• JSON Formatter — Format and validate JSON configuration files before editing glob rules