glob Pattern Tester

Features

• Three dialects handled separately, each with its own meaning for the double star, leading and trailing slashes, and the exclamation prefix
• Every path is reported as matching or not, with matches highlighted
• The pattern is shown as a regular expression so you can check another implementation
• Negated patterns under gitignore or dockerignore are called out (a match there means do not ignore)
• Character classes such as [0-9] and negated ones such as [!0-9] both work; an unclosed bracket is treated as a literal instead of throwing
• Regex metacharacters (dot, plus, parenthesis) are escaped, so *.js does not match aXjs
• A slash followed by a double star matches a itself, and a double star at the front matches a.ts at the root
• Case sensitivity can be turned off

How to use

1. Put the pattern on the first line and one path per line below it
2. Pick the dialect that matches what you are checking
3. Read the per-line verdicts; when one surprises you, look at the regular expression above
4. Edit the pattern and the results update as you type

FAQ

Why does *.js not match src/a.js?

Because in shell rules an asterisk does not cross a path separator, so *.js matches only .js files in the current directory. Use a double star followed by a slash, or src/*.js, to cross directories. This is easy to confuse with regex: .* in a regex crosses everything by default, while a glob star does not cross a slash — and that is exactly where hand-written translators slip and emit .*.

Why does a double star at the front match a.ts at the root?

Because the double star plus slash segment means any number of directories, including none. Someone writing such a pattern wants every .ts file, and a file at the root obviously counts, so that segment has to be allowed to vanish entirely. Many hand-written implementations miss this, and the symptom is that every file under src matches while every file at the root does not.

What does the exclamation mark mean in .gitignore?

Negation: it re-includes something an earlier rule ignored. So when a negated rule matches, it means do not ignore this, which is the opposite of every other rule. That is why it is called out separately here. In shell the same character means something else entirely (history expansion) and has nothing to do with matching, so under the shell dialect it is just a literal character.

Can I validate a whole .gitignore with this?

One pattern at a time. Put the rule you are unsure about on the first line and list the relevant paths below it. Pasting the whole file does not work, because only the first line is read as the pattern. Picking out the two or three doubtful rules and running them separately is far faster than hunting for why one file is not being ignored.