Don't like ads? Go Ad-Free Today 

Ansible Playbook YAML Formatter

DataDeveloper

ADVERTISEMENT · REMOVE?

INPUT

Auto Process

OUTPUT

Client Side

ADVERTISEMENT · REMOVE?

Guide

Ansible Playbook YAML Formatter

Paste any Ansible playbook or task file and get back consistently formatted YAML with task keys in the canonical order (name → module → args → loop → when → register → notify). The tool detects whether you pasted a playbook or a task list, validates the structure, and surfaces ansible-lint style hints — FQCN module names, missing changed_when, command-instead-of-module, and legacy yes/no truthy values — so your playbooks pass review on the first try.

How to Use

Paste your Ansible YAML into the input box — a full playbook.yml, a role’s tasks/main.yml, or any task list.
Leave Reorder Task Keys on to apply the conventional ansible-lint key ordering, or turn it off to keep your original order.
Keep Validate Ansible Structure on for play/task shape checks (missing hosts, tasks without a module, malformed block).
Toggle Show ansible-lint Style Hints for best-practice nudges like FQCN module names, missing names, and idempotency warnings.
Copy the formatted output or download it as playbook.yml.

Features

Conventional task key order – name first, then the module, then args, loop, when, register, notify — the order ansible-lint expects.
Playbook vs task-list detection – Automatically applies play-level ordering (hosts, vars, pre_tasks, tasks, post_tasks, handlers) when a playbook is detected.
Block / rescue / always aware – Reorders nested block-style tasks without breaking their semantics.
Structural validation – Flags plays missing hosts, tasks without a module, malformed lists, and unknown play-level keys.
FQCN hints – Suggests ansible.builtin.apt over bare apt, matching fqcn[action-core].
Idempotency hints – Warns when command/shell runs without changed_when, creates, or removes.
command-instead-of-module detection – Spots shelled-out package installs, systemctl calls, git clones, and pip installs that have first-class modules.
Legacy truthy detection – Flags yes/no/on/off values that should be true/false (yaml[truthy]).
Deprecated loop warnings – Highlights with_items, with_dict, and friends so you can migrate to loop:.
Runs entirely in your browser – Nothing is uploaded; your inventory and secrets stay local.

 FAQ

Why does ansible-lint care about task key order?

Consistent key order makes playbooks scannable: the task's intent (name) reads first, then the module that performs the action, then its arguments, then any control flow (loop, when, register, notify). When everyone on a team follows the same order, diffs stay focused on real changes instead of cosmetic shuffling, and reviewers can pattern-match on tasks at a glance.
What is FQCN and why use it for modules?

FQCN stands for Fully Qualified Collection Name — the full namespace.collection.module path, like ansible.builtin.apt instead of just apt. Since Ansible 2.10 split modules into collections, bare names can resolve ambiguously when multiple collections ship a module with the same short name. FQCNs make resolution explicit, document the source of every module, and protect playbooks from collection ordering changes.
When should I use loop: instead of with_items:?

The with_* lookup-based loops were the original way to iterate, but they couple iteration with lookup plugins, which limits composability. The loop: keyword (introduced in 2.5) takes any list directly and pairs cleanly with loop_control for indexing, labels, and pauses. For simple list iteration, always prefer loop:; only fall back to with_* for the few patterns that don't yet have a clean loop equivalent.
Why is YAML 'yes' considered legacy in Ansible?

YAML 1.1 treated yes, no, on, off, true, and false as booleans. YAML 1.2 narrowed booleans to just true/false. To stay forward-compatible and unambiguous — especially when YAML values are later consumed by tools outside Ansible — ansible-lint's yaml[truthy] rule recommends sticking to true and false. Using the strict booleans also avoids surprises when a literal string yes is needed as data.
Why declare changed_when on command/shell tasks?

Ansible determines whether a task changed the system by inspecting module return data. The command, shell, and raw modules can't know that on their own — they treat any successful execution as a change, which makes idempotency checks lie. Declaring changed_when (or using creates/removes) lets you encode the real change condition: a specific exit code, output pattern, or file marker. Idempotent playbooks become quieter and more diff-able as a result.