All tools

Dockerfile Linter

Code

Lint a Dockerfile for unpinned base images, missing WORKDIR/USER, and misused ADD

Paste a Dockerfile you already have and it checks for 4 common mistakes: a base image with no tag or pinned to `:latest`, which resolves to a moving target rather than a fixed version, a final stage with no WORKDIR, so RUN/CMD/ENTRYPOINT execute from `/` by default, a final stage with no USER, so the container runs as root, and ADD used on a plain local file or directory where COPY would do, since ADD's extra behavior only makes sense for a remote URL or an auto-extracting archive. It understands multi-stage builds: a FROM referencing an earlier named build stage is never flagged for an unpinned tag, and WORKDIR/USER are only checked in the final stage, since that's the one that actually ends up running. This is the deterministic counterpart to the AI Dockerfile Explainer, a fixed set of rule checks rather than a prose walkthrough.

dockerdockerfilelintcontainerdevops

How to use Dockerfile Linter

  • 1.Paste an existing Dockerfile into the editor.
  • 2.Review the flagged findings, each with a rule name, severity, and the exact line number it applies to.
  • 3.Check the parsed build-stage list to confirm which FROM line is treated as the final runtime stage.

Frequently asked questions

How is this different from the Dockerfile Explainer (AI)?
The Explainer sends your Dockerfile to GPT-4o mini for a prose walkthrough and open-ended review. This tool runs a fixed, deterministic set of 4 rule checks entirely in your browser, with no AI and no network call.
Does it check that the base image or tag actually exists?
No, this is pure text parsing. It flags a missing or `:latest` tag, but never contacts a registry to confirm the image or tag is real.
Will it catch every possible Dockerfile mistake?
No, it's built around 4 specific, high-value checks (base image pinning, WORKDIR, USER, ADD vs COPY), not a full best-practices scanner.
How does it handle multi-stage builds?
Each FROM starts a new stage. A stage whose base image is the name of an earlier `AS <name>` stage is never flagged for an unpinned tag, since it isn't a real registry pull. The WORKDIR and USER checks only apply to the final stage, since earlier build stages don't end up in the running container.

Use via API, SDK, or MCP

cURL# Free: 1,000 req/day · Pro: 10,000 req/day
curl -X POST https://api.utilix.tech/v1/tools/dockerfile-linter \
  -H "Authorization: Bearer utx_live_..." \
  -H "Content-Type: application/json" \
  -d '{"content":"FROM node:20.11.1-slim\nWORKDIR /app\nCOPY package.json ./\nRUN npm install\nCOPY . .\nUSER node\nCMD [\"node\", \"index.js\"]"}'

Get an API key from your dashboard · Full API docs →

Related tools

Dockerfile Explainer (AI)Paste a Dockerfile and get a plain-English, instruction-by-instruction walkthrough plus a list of concrete issues worth fixing, powered by GPT-4o miniCodeDockerfile Generator (AI)Describe your app in plain English and get a production-ready Dockerfile back, with multi-stage builds, layer caching, and a non-root user, powered by GPT-4o miniCodeDocker Image ParserParse docker image references into registry, namespace, tag, and digest componentsCode