Gitignore Tester
Paste your .gitignore rules and a list of file paths to see exactly which files are ignored, by which exact rule and line, and which negation rules are silently dead because a parent directory is already ignored.
Processed entirely in your browser — nothing you enter here is ever uploaded.
Result
About this tool
"Why doesn't my .gitignore negation work?" is one of the most common git questions there is, and the honest answer is almost always the same: a `!pattern` trying to re-include a file inside a directory that an earlier rule already excludes can never work, because git does not descend into ignored directories to re-check anything inside them. This tool reimplements git's actual .gitignore matching algorithm — not an approximation — specifically so it can catch and explain that exact situation, along with every other pattern rule git supports.
Paste your .gitignore rules into one box and a list of file paths (one per line, like `dist/index.js`, `node_modules/foo/bar.js`, or `.env`) into the other, and the tool evaluates each path exactly the way git would: comments and blank lines are skipped, trailing spaces are stripped unless escaped, a leading `!` negates a rule, a leading `/` anchors it to the root instead of letting it match at any depth, a trailing `/` restricts it to directories, and `*`, `?`, `[abc]` character classes and `**` (matching across directory boundaries) all work per the documented glob rules.
Critically, paths are checked directory by directory from the root down, the same way git's own ignore engine works — not by testing the full path against every rule in isolation. That is what makes it possible to correctly detect the dead-negation case: if `dist/` is ignored on line 3 and a later `!dist/keep.js` tries to rescue one file inside it, this tool reports `dist/keep.js` as still ignored, names the line-3 rule as the reason, and separately flags the negation as shadowed rather than silently pretending it worked.
The result table gives every tested path its own row with a clear yes/no ignored verdict, the exact rule text and line number that decided it, and — whenever relevant — a plain-language note explaining a shadowed negation or an inherited parent-directory rule. That is the detail that turns a confusing .gitignore into one you can actually reason about before committing.
Example. The pattern *.log ignores error.log and leaves readme.txt unignored.
Limit. Only the pasted rules and the pasted path lines are tested; a real git index and global excludes are not consulted.