b2KIT

Dockerfile Linter

Lint Dockerfiles against best practices with Hadolint-style rules, security checks, and fix suggestions.

Tested tool guide Tested browser tools Checked August 16, 2026

What Dockerfile Linter does and how it behaves

Paste a Dockerfile to identify instructions that conflict with Hadolint-style best practices or common container security guidance. The linter reports questionable constructs and, where it has a supported remedy, provides a fix suggestion. It is useful for reviewing image build recipes before committing them. A clean result does not prove that the image builds, that copied files exist, or that the resulting container is secure. The tool evaluates Dockerfile text, not the completed image.

How the result is produced

1

Dockerfile rule checks

The input is Dockerfile source containing instructions such as FROM, RUN, COPY, USER, and CMD. The tool compares those instructions with its Dockerfile-oriented rule set and reports applicable findings. Hadolint-style describes the kind of maintainability, correctness, and safety checks performed. It does not imply identical rule coverage, diagnostic identifiers, or results across every version of Hadolint.

2

Source-level security review

Security checks identify risky patterns that can be recognized from the Dockerfile itself, while fix suggestions describe a safer or clearer edit when one is available. Processing occurs in the browser, so the pasted source is not uploaded. The linter does not inspect built image layers, registry metadata, build-context contents, installed package vulnerabilities, or behavior that appears only when the container runs.

Good uses

  • checking a pull request Dockerfile for maintainability and security warnings before review
  • screening an inherited Dockerfile for source-visible risks before rebuilding its image
  • getting suggested edits for reported findings instead of interpreting terse lint messages alone

Limits and checks

  • Hadolint-style results should not be assumed to match the exact rule set, severity, or identifiers produced by a particular Hadolint release.
  • A warning can describe an intentional tradeoff. Review the surrounding build requirements before applying its suggested change.
  • No finding confirms only that the available source checks found nothing reportable. It is not evidence that the build succeeds or the image is vulnerability-free.

Common questions

Is this an exact replacement for the Hadolint command-line tool?

No. The stated behavior is Hadolint-style linting, so the tool can apply similar kinds of Dockerfile best-practice checks without promising identical output. Do not depend on exact rule codes, severities, configuration behavior, or version-specific coverage unless the displayed result explicitly provides them. Use the official Hadolint release when exact compatibility is required.

Can the linter tell me whether the resulting container image is secure?

No. It can flag security-relevant patterns visible in the Dockerfile, but it does not establish the security of the resulting image. Package vulnerabilities, unexpected files, inherited base-image contents, exposed secrets, runtime privileges, and application behavior require separate build verification, image scanning, secret detection, and runtime testing.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools