Check a path against .gitignore patterns
Find out whether Git would ignore a file and which rule decides: logs/build.log is ignored because of *.log, the second rule in the list, and a later rule such as !important.log can reverse an earlier one. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Patterns
- dist/, *.log, !important.log, secrets/**
- Path
- logs/build.log
- Matching pattern
- *.log
- Matching index
- 1
Check a repository-relative path against an ordered list of .gitignore patterns without creating a temporary repository or calling Git. The result states whether the path is ignored and, when a rule matched, identifies the last decisive pattern and its zero-based position. The checker understands comments, escaped characters, rooted rules, directory rules, wildcards, character classes, recursive double-star patterns, and negation. It also rejects malformed patterns instead of silently treating an invalid expression as a harmless literal.
Provide rules in their real order
A .gitignore file is not merely a bag of independent globs. Git evaluates its rules in order, and a later matching rule can change the decision made by an earlier one. Send the patterns in exactly the order in which they appear in the relevant ignore file.
Ordinary matching patterns mark the path as ignored, while a rule beginning with an unescaped exclamation mark negates that decision. Blank lines and lines beginning with an unescaped hash are treated as non-rules, just as they are in a normal ignore file. The response includes the last matching pattern and its zero-based array index, which makes it practical to explain a surprising result in a build tool or configuration editor.
Paths must be relative to the repository root and use forward slashes. Supplying a stable, normalized path prevents the same file from receiving different answers merely because one caller included an absolute prefix, a parent-directory segment, or operating-system-specific separators.
Understand the supported matching behavior
A single asterisk matches any number of characters inside one path segment, and a question mark matches one non-slash character. A leading slash anchors a rule at the repository root. A pattern containing no slash can match a name at any depth; if that name denotes a directory in the supplied path, everything beneath it is also covered.
A trailing slash expresses a directory rule. Because the checker receives a path rather than a filesystem tree, it determines the outcome from the path text and its ancestors; it does not inspect whether the final component currently exists as a file or directory. Escaped leading hash and exclamation characters remain literal, and unescaped trailing spaces are discarded according to ignore-file conventions.
Use validation to catch configuration defects
Glob mistakes are easy to miss when an ignore file grows through many small edits. This checker reports invalid input for malformed structures such as an unterminated character class, an empty character class, a dangling escape, or a negation marker without an expression. A successful response does not mutate the rules and does not depend on a network service, current time, random value, repository contents, or host operating system.
That makes it suitable for deterministic pre-commit checks, web forms, IDE diagnostics, and CI policy tests.
What you can do with it
Explain a missing build input
Test the absent path against project ignore rules and show the final rule responsible for excluding it.
Validate an ignore-file editor
Preview how a reordered rule or new negation changes the outcome before saving configuration.
FAQ
Does rule order matter?
Yes. Every rule is evaluated in order, and the last matching rule determines whether the path is ignored.
Are negated patterns supported?
Yes. A leading unescaped exclamation mark creates a negated rule that can make a previously ignored path visible again.
Can patterns match across directories?
Yes. Double-star patterns can cross directory boundaries, while a single star remains within one path segment.
Does it read my repository or my global Git settings?
No. It only compares the path you type with the rules you paste, in their order. Nothing is read from disk, so whether the last part is a file or a folder is judged from the path text alone.
How do I know which rule decided the result?
The answer names the last matching rule and its position in your list, counting from 0. In the example, logs/build.log is ignored by *.log at position 1, which makes a surprising result easy to explain.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/dev2/gitignore-check-path \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"patterns":["dist/","*.log","!important.log"],"path":"logs/build.log"}'const res = await fetch("https://api.kit.forhosting.com/dev2/gitignore-check-path", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"patterns": [
"dist/",
"*.log",
"!important.log"
],
"path": "logs/build.log"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev2/gitignore-check-path",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"patterns": [
"dist/",
"*.log",
"!important.log"
],
"path": "logs/build.log"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/gitignore-check-path", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"patterns":["dist/","*.log","!important.log"],"path":"logs/build.log"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"patterns":["dist/","*.log","!important.log"],"path":"logs/build.log"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/gitignore-check-path", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"patterns": [
"dist/",
"*.log",
"!important.log"
],
"path": "logs/build.log"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.gitignore_check_path",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_patterns | 1000 |
max_pattern_chars | 1024 |
max_path_chars | 4096 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Understand the supported matching behavior
Character classes such as `[0-9]` select one character from a set or range. A double star can cross directory boundaries, so a pattern such as `docs/**/draft*.md` covers drafts directly below `docs` and in deeper folders.
Use validation to catch configuration defects
It also bounds the number and length of patterns so a validation endpoint cannot be turned into unbounded compilation work. When integrating it into automation, keep the returned `matching_pattern` alongside the boolean decision: the explanation is often more useful than the boolean alone. The browser version runs the same pure solver as the API version, while an API request uses the published base price of $0.002.
Integration use cases
Enforce repository policy in CI
Assert that generated artifacts are ignored while required fixtures and source files remain eligible for tracking.
Technical questions
Does the checker read my repository or global Git configuration?
No. It uses only the patterns and repository-relative path supplied in the request.
What happens when a pattern is malformed?
The request fails with an invalid_input error that identifies the pattern position and the structural problem.
What does an API request cost?
The base price is $0.002 per request. The same deterministic solver is also available in the browser.