Pattern Validator
Related tools
Validators and utilities that complement Pattern Validator — same session, no sign-up.
Ctrl+Enter (or ⌘+Enter) to test.
Validate glob patterns and test paths. See which paths match (e.g. src/**/*.ts, *.json).
About this tool
Enter a glob pattern (e.g. *.js, src/**/*.ts, *.{json,yaml}) and a list of paths (one per line). Invalid patterns show an error; valid ones show which paths match.
How to use this tool
- Paste your sample in the input (or fetch from URL if this tool supports it).
- Run the main action on the page to execute Pattern Validator.
- Read the result, fix the source data or config, and re-run if needed.
What this check helps you catch
- Validate glob patterns and test paths. See which paths match (e.g. src/**/*.ts, *.json).
- Limits called out in the description (what this tool does not verify — e.g. live network reachability, issuer databases, or strict schema contracts unless stated).
- Structural or syntax mistakes that would break parsers, serializers, or the next step in your workflow.
FAQ
- What does Pattern Validator do?
- Validate glob patterns and test paths. See which paths match (e.g. src/**/*.ts, *.json). Use the form above, then see “How to use” and “What this check helps you catch” for behavior detail.
- Is this a substitute for server-side validation?
- No. Use it for manual checks and triage; production systems should still validate and authorize on the server.
- Where does processing happen?
- Most validators here run in your browser. If a tool calls an API, that is stated on the page. See the site privacy policy for data handling.
The Pattern Validator helps you test glob patterns against file paths so you can confirm which paths match before using them in build tools, file watchers, ignore rules, or automation scripts. It is useful for developers, DevOps teams, QA engineers, and anyone working with path-based filters in CI/CD pipelines, codebases, or content workflows. By validating patterns such as src/**/*.ts or *.json, you can catch mismatches early, reduce configuration errors, and make path rules easier to reason about across different environments.
How This Validator Works
This validator compares a pattern against one or more test paths and shows whether each path matches the rule. In most cases, glob syntax is used to express file and directory matching behavior, including wildcards, recursive segments, and extensions. The tool is designed to help you verify expected matches before you apply the pattern in a script, linter, bundler, deployment pipeline, or file-processing job.
- Pattern input: Enter a glob-style pattern such as src/**/*.ts.
- Path testing: Provide sample paths to see which ones match.
- Match results: Review matched and unmatched paths to confirm the rule behaves as intended.
- Rule debugging: Use the output to identify overly broad or overly narrow patterns.
Common Validation Errors
Pattern validation issues often come from syntax mistakes, path assumptions, or differences in how tools interpret glob rules. A pattern may look correct but still fail to match because of directory depth, missing wildcards, or platform-specific path separators.
- Incorrect wildcard placement: A single * may match only one segment, while ** is often used for recursive matching.
- Missing file extensions: Patterns like *.json will not match files with other extensions.
- Path separator mismatch: Some tools expect forward slashes, even on Windows.
- Overly broad matches: A pattern may include files you did not intend to target.
- Tool-specific glob behavior: Different libraries and runtimes may interpret patterns differently.
Where This Validator Is Commonly Used
Pattern validation is common anywhere file paths need to be selected, excluded, or processed based on rules. It is especially helpful when path matching affects automation, build output, or content selection.
- Build tools and bundlers
- Test runners and coverage filters
- Linting and formatting configurations
- File watchers and sync tools
- Backup, export, and import workflows
- CI/CD pipelines and deployment scripts
- Content management and static site generation
Why Validation Matters
Path patterns are often used in places where a small mistake can change which files are included, ignored, or processed. Validating patterns before deployment helps reduce configuration drift, avoid accidental omissions, and make automation more predictable. It also improves maintainability by making rules easier for teams to review and understand.
For shared repositories and production pipelines, clear pattern behavior supports safer releases and fewer surprises during builds, tests, and file operations.
Technical Details
Glob patterns are a compact way to describe sets of paths. They are commonly used in developer tooling, but exact behavior can vary by implementation. This validator is intended to help you inspect matching logic at a practical level, especially when working with recursive directories, file extensions, and ignore/include rules.
| Pattern type | Glob-style path matching |
| Common tokens | *, **, ?, extensions, directory segments |
| Typical use cases | Include rules, ignore rules, file selection, automation filters |
| Important note | Matching behavior may differ across tools and libraries |
If you are validating patterns for a specific platform, compare results with that platform’s documentation to confirm edge-case behavior such as dotfiles, root-relative matching, and separator handling.
Frequently Asked Questions
What is a glob pattern?
A glob pattern is a shorthand syntax used to match file and folder paths. It is commonly used in developer tools to include or exclude files without listing each path individually. Examples include *.json for JSON files and src/**/*.ts for TypeScript files in nested folders.
What does the double asterisk mean in a pattern?
The double asterisk, often written as **, usually means recursive matching across multiple directory levels. For example, src/**/*.ts is often used to match TypeScript files anywhere under src. Exact behavior can vary depending on the tool or library interpreting the pattern.
Why does my pattern not match a file I expected?
Common reasons include missing wildcards, incorrect directory depth, path separator differences, or tool-specific glob rules. A pattern may also fail if the file extension, hidden-file behavior, or root-relative path format does not align with the matcher’s expectations.
Can this validator help with ignore rules?
Yes. Pattern validators are useful for testing ignore and include rules before you add them to configuration files. This can help you confirm which files are excluded from builds, backups, scans, or formatting steps, especially when multiple patterns interact.
Are glob patterns the same across all tools?
No. Many tools use glob-style syntax, but implementations may differ in how they handle recursive matching, dotfiles, root paths, and separators. It is a good practice to validate your pattern in the same environment where it will be used, or compare it against the relevant documentation.
Can I use this for CI/CD configuration?
Yes. Pattern validation is especially helpful in CI/CD pipelines where file selection affects tests, deployments, and artifact generation. Testing patterns in advance can reduce configuration errors and make automated workflows more reliable.
Does a pattern validator check file contents?
No. A pattern validator checks whether a path matches a rule. It does not inspect file contents, metadata, or security status. If you need content analysis, you would use a different type of validator or scanner designed for that purpose.
What is the difference between * and **?
In many glob systems, * matches characters within a single path segment, while ** can match across directory boundaries. That distinction is important when you want to target files only in one folder versus files in nested subfolders as well.
Is this useful for cross-platform development?
Yes. Path matching can behave differently across operating systems and tools, especially when separators or root paths are involved. Testing patterns helps teams spot portability issues before they affect builds, scripts, or deployment jobs on another platform.
Related Validators & Checkers
- JSON Validator — validate structured JSON syntax and formatting
- XML Validator — check XML structure and well-formedness
- URL Validator — verify URL format and structure
- Regex Validator — test regular expression patterns and matches
- File Path Validator — check path formatting and path-related rules