Drop any file to identify it
No upload. No signup. No sending your file halfway across the internet.
We tell you what it is, right here in your browser.
Drop it!
Let go to identify this file.
Couldn't identify this file
Need to convert it? fwip it →
Before Docker can build an image, it has to send the entire build context — every file in the directory you ran `docker build` from — to the Docker daemon. If that directory contains `node_modules/` (300 MB), `.git/` (50 MB), build artefacts, log files, and your local `.env` with API keys, all of it gets shipped over for the build, even if your Dockerfile never copies them in.
The .dockerignore file lives next to your Dockerfile and lists patterns to exclude from the build context, gitignore-style. A typical .dockerignore: `node_modules`, `.git`, `*.log`, `.env`, `dist`, `build`, `.DS_Store`, `coverage`. The result is faster uploads, smaller cache invalidations (changes in ignored files don't bust your build cache), and fewer secrets accidentally baked into images. If your Dockerfile uses `COPY . /app`, this file is the only thing standing between your Docker image and your `.env` file.
The syntax is largely the same as .gitignore — glob patterns, `!` for re-includes, `#` for comments — but with a few quirks. Path matching is anchored at the build context root (no leading-slash ambiguity), and patterns are evaluated relative to that root. Don't confuse .dockerignore with .gitignore: they serve different purposes, and you almost always want both. The .gitignore protects your repo from junk; the .dockerignore protects your image from bloat and secrets.