Why should I avoid the :latest tag?

The :latest tag points to a different image every time the upstream maintainer pushes a new build. Your image will silently pick up new base OS packages, potentially breaking your build or introducing vulnerabilities. Pin to a specific digest or version tag (e.g. node:20.11-alpine3.19) for reproducible builds.

Why use exec form for CMD and ENTRYPOINT?

Shell form (CMD npm start) runs your process as a child of /bin/sh, which means Docker's SIGTERM on container stop never reaches it. Exec form (CMD ["npm", "start"]) runs the process directly as PID 1, so it receives signals and can shut down gracefully.

Why combine apt-get update and install in one RUN?

Docker caches each RUN layer. If you split them, the update layer is cached and never re-run, so subsequent installs use a stale package index. Combining them on one line ensures the index is always fresh when packages are installed.

Why use COPY instead of ADD?

ADD has implicit behavior: it auto-extracts local tar archives and can fetch remote URLs. This makes Dockerfiles harder to reason about. Use COPY for plain file copying so the intent is explicit. Reserve ADD only when you specifically need tar extraction.

Private by defaultRuns in your browser

Dockerfile validator

Paste your Dockerfile and get a line-by-line lint report covering security, reproducibility, and best-practice issues.

Dockerfilepaste your Dockerfile

Quick samplesClick to load

Dockerfile Validator

About this tool

A Dockerfile that builds successfully is not necessarily a good Dockerfile. Common mistakes — using the :latest tag, running containers as root, forgetting to clean apt caches, using ADD when COPY is correct, or writing CMD in shell form instead of exec form — produce images that are oversized, insecure, or non-reproducible, yet they never cause a build error. This tool parses your Dockerfile and runs a set of lint rules inspired by Hadolint, the widely-used Dockerfile linter, highlighting issues at the line where they occur. Each finding is classified as an error (will cause problems), a warning (likely to cause problems), or an info note (best-practice improvement). Errors include unknown instructions and FROM not being the first directive. Warnings cover unpinned base image tags, ADD used instead of COPY, apt-get update run without install in the same layer, missing apt cache cleanup, MAINTAINER usage, CMD and ENTRYPOINT written in shell form, and containers running as root. Info notes flag missing HEALTHCHECK, relative WORKDIR paths, and pip installs without pinned versions. A summary strip at the top shows the count of each severity level at a glance. The full Dockerfile is shown line by line with each issue annotated inline so you can see exactly where to make changes.

No signup requiredRuns in your browserInstant results

How to use

1
Paste your Dockerfile contents into the input field.
2
Click Validate — issues appear instantly.
3
Each row shows the line number, severity (ERROR / WARNING / INFO), and a description of the problem.
4
Fix the flagged lines, paste the updated Dockerfile, and re-validate until you see a clean result.

Why use this tool?

→
Catch unpinned base image tags before they break reproducible builds.
→
Ensure containers don't run as root before pushing to production.
→
Audit a third-party Dockerfile for security and size issues before using it.
→
Learn Dockerfile best practices interactively with annotated feedback.

ExamplesInput → output

Unpinned base image

Input

FROM node:latest
RUN npm install

OutputWARNING DL3007 — Avoid :latest tag; pin to a specific version.

apt-get without cleanup

InputRUN apt-get update && apt-get install -y curl

OutputWARNING — Clean apt cache in the same layer: && rm -rf /var/lib/apt/lists/*

Common errorsAnd how to fix them

First instruction must be FROM

Cause: A Dockerfile must start with a FROM instruction (or ARG before FROM for build-time variables). Any other instruction first is a hard error.

Fix: Move your FROM line to the top of the file. ARG instructions for build arguments used in FROM (e.g. ARG BASE_IMAGE) may appear before it.

Unknown instruction

Cause: A line starts with a word that is not a valid Dockerfile instruction. Often caused by a typo (e.g. COPY vs CPOY) or pasting non-Dockerfile content.

Fix: Check the spelling. Valid instructions are: FROM, RUN, CMD, LABEL, EXPOSE, ENV, ADD, COPY, ENTRYPOINT, VOLUME, USER, WORKDIR, ARG, ONBUILD, STOPSIGNAL, HEALTHCHECK, SHELL.

Frequently asked questionsCommon questions answered

These answers explain common dockerfile validator tasks, expected input formats, and edge cases so both visitors and search engines can understand what this tool does.

Why should I avoid the :latest tag?: The :latest tag points to a different image every time the upstream maintainer pushes a new build. Your image will silently pick up new base OS packages, potentially breaking your build or introducing vulnerabilities. Pin to a specific digest or version tag (e.g. node:20.11-alpine3.19) for reproducible builds.
Why use exec form for CMD and ENTRYPOINT?: Shell form (CMD npm start) runs your process as a child of /bin/sh, which means Docker's SIGTERM on container stop never reaches it. Exec form (CMD ["npm", "start"]) runs the process directly as PID 1, so it receives signals and can shut down gracefully.
Why combine apt-get update and install in one RUN?: Docker caches each RUN layer. If you split them, the update layer is cached and never re-run, so subsequent installs use a stale package index. Combining them on one line ensures the index is always fresh when packages are installed.
Why use COPY instead of ADD?: ADD has implicit behavior: it auto-extracts local tar archives and can fetch remote URLs. This makes Dockerfiles harder to reason about. Use COPY for plain file copying so the intent is explicit. Reserve ADD only when you specifically need tar extraction.