Developer Tools · Developer
Dockerfile Linter
Lint your Dockerfile in the browser: detect best-practice violations line by line with clear explanations and fixes, plus a structure summary.Runs in your browser
Last updated:
How to use
Expand how to useCollapse how to use
- 1
Paste your Dockerfile
Paste the Dockerfile you want to check into the text area. You can also start from a sample.
- 2
Review issues, reasons, and fixes
Detected violations are listed by severity. Each item shows why it matters and how to fix it. Click a line number to jump to that line.
- 3
Check the structure summary
See the instruction count, number of stages, estimated layers, and multi-stage dependencies to grasp the structure quickly.
Dockerfile
Paste a Dockerfile to detect best-practice violations. You can also start from a sample.
What is the Dockerfile Linter?
The Dockerfile Linter analyzes your Dockerfile in the browser and detects best-practice violations line by line. It checks for unpinned tags (relying on latest), misuse of ADD for local files, shell-form CMD/ENTRYPOINT, the deprecated MAINTAINER instruction, relative WORKDIR paths, consecutive RUN instructions, and multi-stage stage-reference mistakes, using 15 rules inspired by hadolint. Each finding includes the reason it matters and a concrete fix, so you can understand the intent behind every rule while you fix it. It also visualizes a structure summary—instruction count, number of stages, estimated layers, and multi-stage dependencies—so you can grasp the overall shape of your Dockerfile at a glance. Everything runs in your browser, and your input is never sent to any external server.
Key features
- Detects best-practice violations line by line (15 rules)
- Shows the reason and a concrete fix for each finding
- Visualizes a structure summary: instructions, stages, and estimated layers
- Runs entirely in your browser with no external data transfer
When it helps
- Checking a Dockerfile while writing or reviewing it
- Verifying stage references in multi-stage builds
- Catching anti-patterns like latest tags or ADD misuse early
- A quick local check before adopting hadolint in CI
Frequently asked questions
Is my Dockerfile sent to any external server?
No. All parsing and linting runs in your browser with JavaScript, and your Dockerfile is never sent to an external server.
When should I use COPY vs ADD?
Use COPY for plain file and directory copies. ADD has extra behavior—auto-extracting tar archives and fetching remote URLs—so use it only when you need those features.
Why should I avoid the latest tag?
latest can be updated under the same name, so each build may use a different image. Pinning a specific version like node:20.11-slim makes builds reproducible.
What is a multi-stage build?
It uses multiple FROM instructions in one Dockerfile and copies only the artifacts from a build stage into the final image with COPY --from, keeping the final image small. This tool visualizes the dependencies between stages.
How is this different from hadolint?
This tool uses a hadolint-inspired rule set, shows the reason and fix for each finding, and runs entirely in the browser. For automated checks in CI, pair it with a CLI such as hadolint.
How is this different from `docker build --check`?
`docker build --check` is Docker's official check feature: BuildKit (Buildx 0.15.0 or later) validates your Dockerfile in an environment with Docker installed, and the --check flag runs the checks without executing the build. This tool needs no installation and runs entirely in your browser—just paste your Dockerfile and check it right away. For a quick check on your machine, use this tool; in CI or build pipelines, pair it with `docker build --check` or hadolint.