Loading…

About Free Online Dockerfile Formatter

Messy Dockerfile? Broken indentation, inconsistent spacing and unreadable RUN chains? This Dockerfile Formatter uses a dprint-based engine (via a secure backend) to normalize your Dockerfiles and Containerfiles with a clean, opinionated layout. It keeps your instructions exactly in place while making the file easier to review, version and automate across environments.

Key Features of the Dockerfile Formatter

  • Cleans indentation, spacing and line wrapping for Dockerfiles and Containerfiles
  • Normalizes multi-line RUN instructions with consistent backslashes and indentation
  • Respects Dockerfile semantics – no instruction reordering, no shell logic changes
  • Deterministic output: same input and version ⇒ same formatted Dockerfile
  • Perfect companion for pre-commit hooks, monorepos and CI jobs using dprint
  • Web-based editor with syntax highlighting, diff-friendly output and copy/download actions
  • Works well with multi-stage builds, build args and typical Node/.NET/Go images

🛠️ How to Format a Dockerfile for dockerfile-formatter

1

1. Paste or Upload Your Dockerfile

Paste your Dockerfile into the editor or drop a Dockerfile/Containerfile from your project. Small snippets (like a single FROM/RUN block) work too if you just want to experiment.

2

2. Run the Formatter

Click "Format". The tool sends your source to a secure, dprint-based backend that adjusts indentation, spacing, array-style instructions and multi-line RUN chains without touching the execution logic.

3

3. Review, Copy or Download

Compare the formatted output with your original file. When you're satisfied, copy the result back into your repo or download the formatted Dockerfile to commit it directly.

Technical Details

Supported File Types

The formatter targets Docker build instructions and compatible container build files used across Docker, Podman and similar tools.

TypeExampleNotes
DockerfileDockerfile, Dockerfile.prod, Dockerfile.node18Classic Docker build files for images
ContainerfileContainerfilePodman / Buildah style configuration files
Inline snippetsFROM node:18-alpineSmall fragments or examples are also supported for quick tests

Formatting Behaviour (dprint-style)

High-level behaviours of the underlying dprint plugin used by this tool:

AreaBehaviourExample
IndentationNormalizes indentation for continued lines in RUN and other instructionsRUN set -eux; \\n npm ci; \\n npm cache clean --force
Lists & arraysCleans spacing in JSON-style arrays for CMD/ENTRYPOINT/HEALTHCHECKCMD ["npm", "start"] → CMD ["npm", "start"] (but with consistent spaces)
SpacingRemoves redundant spaces around instructions while preserving meaningENV NODE_ENV=production
Line wrappingMay reflow long RUN chains for readability without changing orderLong shell pipelines become easier to scan and review in diffs
CommentsPreserves full-line and inline comments beside instructions# base image for build stage\nFROM node:18 AS build

Non-goals

This formatter is intentionally scoped to layout, so you can combine it with other DevOps tools:

ItemHandled?Notes
Hadolint-style linting❌Use hadolint or similar tools for best-practice checks and warnings
Security scanning❌No CVE or vulnerability scanning of images or registries
Image building❌Does not execute docker build or interact with Docker Engine
Instruction reordering❌Never reorders instructions; only indentation and whitespace change
Base image hardening❌Does not recommend base images; it formats whatever you provide

CLI & CI Equivalents

Like the result? Mirror the same behaviour locally and in CI with dprint and complementary tools.

Universal (dprint)

Initialize dprint and add Dockerfile plugin

dprint init
# In dprint.json, add:
# {
#   "plugins": ["https://plugins.dprint.dev/dockerfile-0.x.wasm"]
# }
# Then format your Dockerfiles:
dprint fmt Dockerfile

Closest match to this online formatter, so developers and CI use the same style.

Linux/macOS

Lint with hadolint (complements formatting)

hadolint Dockerfile

Combine formatting (style) with linting (best practices, smaller images, healthchecks).

Git / pre-commit

Run dprint on changed Dockerfiles before commit

# .pre-commit-config.yaml (conceptual)
- repo: local
  hooks:
    - id: dprint-dockerfile
      name: dprint Dockerfiles
      entry: dprint fmt
      language: system
      files: "(Dockerfile|Containerfile)$"

Guarantees that every Dockerfile merged to main is already formatted.

Common Use Cases

Dev & Platform Engineering

  • Normalize Dockerfiles across microservices before code review
  • Clean up legacy Dockerfiles inherited from multiple teams or templates
  • Standardize style when migrating images, base OS versions or build strategies
# Typical multi-stage Dockerfile (clean, review-friendly)\nFROM node:18 AS build\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci && npm cache clean --force\nCOPY . .\nRUN npm run build\n\nFROM node:18-alpine\nWORKDIR /app\nCOPY --from=build /app/dist ./\nCMD ["node", "index.js"]

CI/CD Pipelines

  • Fail builds when Dockerfiles are not properly formatted
  • Auto-fix style on feature branches via pre-commit hooks or CI jobs
  • Keep Docker configuration readable in long-lived monorepos and platform repos
# Example Git pre-commit hook (pseudo-code)\n#!/bin/sh\nchanged=$(git diff --cached --name-only --diff-filter=ACM | grep -E 'Dockerfile|Containerfile' || true)\n[ -z "$changed" ] && exit 0\ndprint fmt $changed\ngit add $changed

Team Onboarding & Consistency

  • Give new team members a single, opinionated Dockerfile style to follow
  • Remove code-style debates from PRs: let the formatter be the source of truth
  • Align local formatting, repo hooks and CI jobs around the same dprint config
# Example snippet for docs/onboarding.md\n1. Install dprint locally\n2. Copy the shared dprint.json from the platform repo\n3. Run `dprint fmt Dockerfile` before opening a pull request

❓ Frequently Asked Questions

Does formatting change how my image builds?

No. The formatter only touches whitespace, indentation and line wrapping. It preserves the order and content of your Dockerfile instructions. As long as your original Dockerfile was valid, the resulting image build should behave the same.

Is this the same as linting with hadolint?

No. This tool is a formatter, not a linter. It fixes style and layout issues (spacing, indentation, wrapping), but it will not warn you about best practices (like using specific base images, healthchecks, or layer sizes). For that, combine it with hadolint or another Dockerfile linter.

Can I enforce this style in CI?

Yes. You can configure dprint with the Dockerfile plugin in your repository and run `dprint fmt` (or `dprint check`) in your CI pipeline. That way, CI can fail when Dockerfiles deviate from the expected style, matching what you see in this online formatter.

Does it support multi-stage builds?

Yes. Multi-stage Dockerfiles are formatted just like any other file. Each FROM, COPY, RUN and ENV instruction is preserved, and the layout is made consistent across all stages without changing build semantics.

Is my Dockerfile uploaded to a server?

For this tool, formatting is performed via a secure backend endpoint using a dprint-based formatter. Your source is used to compute the response and is not intended to be stored long term. As always, avoid pasting highly confidential infrastructure details into any online tool unless you control the full stack.

Pro Tips

Best Practice

Run formatting automatically in CI so Dockerfile style never drifts between services or teams.

Best Practice

Pair this formatter with a linter like hadolint to cover both layout and best-practice guidance.

Best Practice

Agree on a standard multi-stage Dockerfile template early in a project and keep it formatted so new services follow the same structure.

Best Practice

If you work in a monorepo, share a single dprint configuration so application code, infra code and Dockerfiles use consistent conventions.

Additional Resources

Dockerfile reference
Documentation
Best practices for writing Dockerfiles
Reference
dprint Dockerfile plugin
Documentation
hadolint – Dockerfile linter
Documentation

Other Tools