Dockerfile Linter & Formatter — Best Practices Tidy a Dockerfile and flag common issues.
100% offline
Input231 chars · 13 lines
Output1 warnings231 chars
Formatted · 1 warning
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:1.27-alpine
WORKDIR /usr/share/nginx/html
COPY --from=build /app/dist .
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

About Dockerfile Linter & Formatter — Best Practices

A Dockerfile is a small program that builds a container image, and small slips — an inconsistent instruction casing here, an unpinned base image there — quietly cause flaky, non-reproducible builds. This free Dockerfile formatter and linter tidies the file and points out the issues that bite teams most.

The formatter uppercases instruction keywords (FROM, RUN, COPY…), normalizes the spacing after each keyword, and re-indents multi-line RUN continuations so the file reads cleanly. The Dockerfile linter then flags common problems: an unpinned or :latest base image, ADD where a plain COPY would do, "apt-get upgrade", using "cd" instead of WORKDIR, missing FROM or WORKDIR, multiple CMDs, and RUN layers that could be combined.

Everything runs entirely in your browser — your Dockerfile never leaves the device, so it is safe to paste config from a private repo.

Features

  • Format: uppercase instructions, normalize spacing, re-indent RUN continuations
  • Lint: unpinned/latest images, ADD vs COPY, apt-get upgrade, cd vs WORKDIR
  • Catches missing FROM, missing WORKDIR, multiple CMDs, and combinable RUN layers
  • Fully offline — your Dockerfile is never uploaded

How to use

  1. Paste your Dockerfile into the input pane.
  2. Click Format to normalize casing, spacing, and continuation indentation.
  3. Click Lint to list best-practice issues, each tagged with its line number.
  4. Copy the formatted result, or fix the flagged lines and re-lint.

Frequently asked questions

Why pin the base image version instead of using latest?

The "latest" tag (or no tag) changes over time, so the same Dockerfile can produce different images on different days. Pinning an explicit tag — or better, a digest — keeps builds reproducible and avoids surprise breakages.

When should I use COPY instead of ADD?

Use COPY for plain file and directory copies; it is explicit and predictable. ADD has extra magic — it can fetch remote URLs and auto-extract local tar archives — so reserve it for exactly those cases. The linter flags ADD only when a COPY would do the same job.

Why does the linter complain about "cd" in a RUN?

A "cd" only changes the working directory for that single RUN layer; the next instruction starts back at the previous directory. Use WORKDIR instead, which persists across instructions and is the documented way to set the build/runtime directory.

Does my Dockerfile get sent to a server?

No. Both the formatter and the linter run locally in your browser. Nothing you paste is uploaded, logged, or stored, so it is safe to use with Dockerfiles from private repositories.

Everything runs locally in your browser — your input is never uploaded.