01
Start with the stage list
The sample contains build and runtime stages. Open Stages & instructions and click a stage number to move the editor to its FROM declaration. Stage indices start at zero.
Docker / Containers
Dockerfile editor
Inspect a multi-stage file, follow a diagnostic to its source, and review formatting before applying it.
Dockerfile editor
Dockerfile source
Result
Runs in this browser. Source stays in memory; no build or registry requests.
Result is out of date. Check again before exporting.
Use this Dockerfile editor when a container recipe becomes difficult to review: find the boundary between the build and runtime stages without losing the original lines.
A Dockerfile validator and Dockerfile formatter serve different purposes. This Dockerfile linter reports a supported set of static issues; its multi-stage Dockerfile outline helps you inspect the file, not prove that an image will build.
Why use this Dockerfile editor
Follow the stage boundary
The Dockerfile editor lists each FROM in source order, including unnamed stages. Jump from a stage card to its declaration and inspect the instructions that follow, before deciding where a copied artifact belongs.
Review a small, reversible change
The formatter produces a separate result. Compare continuation indentation, inspect the number of changed lines, and apply only when satisfied. One undo restores the preceding input and result together.
Review without losing your place
02
Control when checks run
Automatic checks wait 350 ms after edits. Turn them off to inspect an unfinished line without rerunning; Ctrl/Cmd + Enter performs the next manual check. Editing also disables stale exports.
03
Apply only the reviewed text
Choose two spaces, four spaces or a tab for continuations. Preview formatting shows the changed-line count. Applying changes keeps an undo snapshot; a subsequent edit invalidates the preview.
Inspect structure and supported diagnostics
Line and column locations
Diagnostics distinguish errors from warnings and link back to the source. Localized categories explain the concern; expandable details retain the engine’s original English message and diagnostic code.
Instructions in context
Expand an instruction to see its original text and a concise explanation. FROM starts stages; ARG scope differs from ENV; EXPOSE documents a port without publishing it. Shell commands are displayed, never interpreted.
Comments and heredocs
Formatting preserves comments, instruction case and order. The parser recognizes continuation lines and heredocs; an unterminated heredoc is an error. A JSON-looking argument that is not a string array produces an intent warning.
What a static review can establish
- No build or security verdict
- This page does not execute RUN, pull images, inspect dependencies or read the build context. It cannot establish file existence, image availability, successful builds, vulnerability status or policy compliance.
- A limited rule set
- The installed parser does not replace Hadolint, ShellCheck or all BuildKit checks. Frontend extensions may exceed its support. An engine ignore comment is honored, and a warning makes that suppression visible.
- No semantic rewrites
- Formatting adjusts instruction indentation, whitespace-only lines and continuation indentation. It does not uppercase instructions, merge RUN lines, reorder packages or rewrite shell bodies. COPY --from may name an external image, not just a stage.
- Explicit input and display limits
- Paste one file, up to 131072 UTF-16 code units and 2000 physical lines. Larger inputs stop processing without truncation. Lists show 50 entries at a time; exports contain the complete current formatted text with LF line endings.
Dockerfile editor FAQ
Can an online check replace runtime tests?
No. Static diagnostics cannot reproduce the build context, image state, network or runtime behavior. Run the real build and appropriate container tests in your own environment after reviewing the file.
Does formatting alter the build behavior?
The intended changes are whitespace formatting, not command rewrites. Review the separate output and changed-line count before applying it, especially around continued commands. Undo restores the prior state.
Can I format a multi-stage Dockerfile?
Yes. Each FROM starts an outline entry with its image, optional name and source position. The formatter preserves stage order and COPY --from references; it does not optimize or combine stages.
How does formatting differ from hadolint?
Hadolint provides a different lint rule set, including shell-oriented checks. This page uses a JavaScript Dockerfile parser and validator; a clean result here does not mean Hadolint or BuildKit will accept every construct.
Can Dockerfile formatting run in CI?
This interactive page does not run in CI for you. Use a pinned formatter or linter in your pipeline and review its configuration independently; this page does not export a pipeline configuration.
Still have a question?
Review the next change
Return to the Dockerfile editor, inspect one diagnostic or stage boundary, and export the current preview when it matches your intent.
Static checks are a review aid; verify the actual build separately.