Paste rules and paths to review the expected build context. This text-based matcher does not read your repository or run a Docker build.
Runs locally in your browserThe left box takes the content of a .dockerignore file and the right box takes candidate paths, one per line, relative to the build-context root. Press Test build context and every candidate gets a verdict: excluded or included, together with the rule that decided it and a note when the match came from a parent folder. The right column also shows the normalized rule list — the lines Docker actually reads — and a report of the usual build-context risks.
.dockerignore tells the Docker client which files to leave out of the build context, the tree that is sent to the daemon and that ADD and COPY can see. This page reads that text and nothing else: it does not open your repository, does not walk a real context folder and does not run a build. Everything below describes the matching rules the page applies, which follow the implementation Docker uses.
The reader drops a UTF-8 byte-order mark on the first line, ignores lines whose first character is # and skips empty lines; a # that only appears after spaces is a pattern, not a comment. Each remaining line is trimmed, an initial ! marks an exception, and the rest is cleaned like a path: ./x becomes x, a//b becomes a/b, a/../b becomes b, foo/ becomes foo. One leading / is then removed, so /foo and foo are the same pattern. A line that is only ! is an error — Docker stops with "illegal exclusion pattern".
Patterns that do not survive that cleaning are reported before a build would start: an unterminated [ class, a ] or - in the wrong place inside a class, or a pattern that ends with a backslash. The page names the line number and the offending text instead of quietly echoing the file, and it does not guess what you meant.
Every candidate is compared with the patterns from top to bottom and the last matching pattern decides; a later exception can therefore undo an earlier exclusion. A pattern is matched against the full path relative to the context root, so *.md covers markdown files at the root while **/*.md covers every depth. A single * or ? never crosses a /, ** crosses directories (a/**/b also matches a/b, and **/foo also matches a top-level foo), [0-9] and [^a-z] are character classes, and a backslash escapes the next character.
A pattern also decides for everything inside a folder it matches, which is why node_modules excludes node_modules/react/index.js; the results say so explicitly with the parent-folder note. Because only the last matching rule counts, a ! line that is reached while nothing is excluded brings nothing back, and the report lists those ineffective lines.
The verdicts are text verdicts. The page never walks your repository, so a file that is not in the candidate list is never examined, and a candidate list is a sample rather than the real context. Docker versions differ slightly in how they transfer and filter contexts, so an unusual pattern is worth re-checking with the client you build with.
.dockerignore only shapes what the client sends to the daemon. It does not create image layers by itself, does not affect runtime mounts, and does not change what a COPY or ADD instruction matches at build time — a file that stays in the context can still be copied, and a file that is excluded makes a COPY fail when the Dockerfile expects it. Check the copy paths as well.