Gitignore Tester

How to use

1. 1Paste your .gitignore rules into the left panel, one pattern per line, or click Load sample to start from a realistic set.
2. 2Paste the file paths you want to test into the right panel, one per line, relative to the repository root. End a path with a slash to test it as a directory.
3. 3Read each result: a green Tracked or red Ignored badge, the deciding line number, and a plain-English reason. The matched pattern is shown beneath each path.
4. 4When a negation does not work, look for the excluded parent note: git cannot re-include a file inside an ignored directory, so re-include the directory first.
5. 5Open Pattern breakdown to see whether each rule is anchored, directory-only, or a re-include, and to catch any flagged malformed lines.
6. 6Toggle Show ignored only to focus on hidden files, and use Copy ignored or Copy tracked to grab either list as text.

About this tool

Gitignore Tester answers the question the gitignore generator cannot: given this exact .gitignore, is this file ignored, and which line decided it? Paste your ignore rules on the left and the file paths you want to check on the right, and every path gets a clear Ignored or Tracked verdict, the line number and text of the pattern that decided it, and a plain-English reason. It exists because gitignore matching is not the same as ordinary glob matching, and the differences are exactly where people get stuck. This tool reproduces the rules from gitignore(5) for a single ignore file at the repository root. A pattern with no slash, like build, matches that name at any depth, while a leading slash anchors it to the root, so /build matches only the top-level directory and not src/build. A trailing slash makes a pattern match directories only, so logs/ never ignores a regular file named logs. A single star matches anything except a slash, a question mark matches one non-slash character, square brackets are a character class, and a double star crosses slashes in its three forms: a leading star-star-slash that matches in every directory, a trailing slash-star-star that matches everything inside, and a middle a/**/b that allows zero or more directories between the two names. The resolution rules matter as much as the syntax. The last pattern that matches a path wins, so order changes the outcome, and a leading exclamation mark re-includes a path that an earlier pattern ignored. The single most misunderstood rule is the one this tool makes obvious: git cannot re-include a file if one of its parent directories is ignored, because git never looks inside an ignored directory, so a rule like coverage/ followed by !coverage/summary.json still leaves the file ignored, and the tool says so and tells you to re-include the directory first. Comments starting with a hash, blank lines, trailing-space trimming, and backslash escaping of a literal leading hash or exclamation mark are all handled. A pattern breakdown panel shows, for each rule, whether it is anchored or matches at any depth, whether it is directory-only, and whether it re-includes, and it flags malformed lines such as a bare exclamation mark. Sample rules and paths load a realistic mix (a build directory, node_modules, log files, an allowlisted .env.example, an excluded coverage folder with a re-include that does not work, and Python caches) so you can see the behavior before pasting your own. Type a path with a trailing slash to test it as a directory, copy the ignored or the tracked list as newline-separated text, and toggle Show ignored only to focus on what git will hide. One honest limit: this evaluates one root .gitignore, not multiple nested ignore files, your global core.excludesFile, or .git/info/exclude, and it does not read your working tree, so it tells you what the rules you paste would do. Everything runs locally in your browser; the rules and paths you enter are never uploaded or logged.

Free to use. Works in your browser. No signup, no login.