JSON to YAML for Ansible Playbooks – Migrate Config Without Rewriting

Infrastructure state exported from a cloud provider API arrives as JSON. Your Ansible playbook expects YAML. Rewriting the entire resource definition by hand — translating every brace to indentation, every comma to a newline, every quoted key to an unquoted one — is error-prone and slow. A JSON to YAML converter handles the structural transformation; you handle the Ansible-specific patterns that differ from generic YAML.

Ansible playbooks are YAML, but they use YAML in specific ways that require attention during conversion. Boolean handling is different. Variable interpolation uses Jinja2 template syntax that must be preserved. The vars block has strict indentation rules relative to its parent task or play. Understanding these patterns turns a mechanical conversion into a correctly structured playbook.

// JSON task definition from API export:
{
  "name": "Configure application server",
  "hosts": "app_servers",
  "become": true,
  "vars": {
    "app_port": 8080,
    "debug_mode": false,
    "log_level": "info"
  },
  "tasks": [
    {
      "name": "Install dependencies",
      "package": {
        "name": "{{ item }}",
        "state": "present"
      },
      "loop": ["nginx", "python3", "supervisor"]
    }
  ]
}

# Converted to Ansible YAML — correct structure:
- name: Configure application server
  hosts: app_servers
  become: true
  vars:
    app_port: 8080
    debug_mode: false
    log_level: info
  tasks:
    - name: Install dependencies
      package:
        name: "{{ item }}"  # ← Jinja2 template — keep quoted
        state: present
      loop:
        - nginx
        - python3
        - supervisor

When You Need to Convert JSON to Ansible YAML

JSON-to-Ansible conversion comes up in several common infrastructure workflows.

• Cloud API exports to playbooks. AWS, Azure, and GCP APIs return resource definitions as JSON. Converting a cloud resource export into an Ansible task creates a starting point for managing that resource through Ansible without rewriting the full definition.
• Terraform state to Ansible variables. Terraform outputs can be written as JSON. Converting terraform output JSON to an Ansible vars file populates variables from infrastructure state without manually copying values.
• Legacy JSON config migration. If your team previously stored configuration as JSON and is moving to YAML for consistency with the rest of the DevOps toolchain, converting the JSON config files to YAML variables files is a one-time migration task.
• Integrating JSON-outputting tools into Ansible workflows. Some tools — cloud inventory scripts, service discovery APIs, monitoring exports — produce JSON. Converting their output to Ansible YAML structures allows it to be used in playbooks directly.

For the general JSON to YAML conversion workflow, see our guide on JSON to YAML conversion. For validating the resulting YAML, see the YAML Validator.

Ansible-Specific YAML Patterns

Ansible uses standard YAML, but it has conventions and requirements that differ from generic YAML conversion.

Jinja2 templates must be quoted. Any YAML value that starts with {{ must be quoted — otherwise the YAML parser interprets the double braces as a flow mapping. name: {{ item }} is a YAML parse error. name: "{{ item }}" is correct.

# ✗ Breaks YAML parser:
  name: {{ item }}

# ✓ Quote Jinja2 expressions:
  name: "{{ item }}"
  path: "/etc/{{ app_name }}/config.yml"

Boolean field names are Ansible-specific. Ansible uses become: true for privilege escalation, not sudo: true. The boolean values themselves — true/false — are standard YAML booleans. After converting from JSON, verify that boolean field names match Ansible's module parameter names, not generic terms.

The vars block indentation is strict. Variables declared at the play level are under vars: with the same indentation as hosts: and tasks:. Variables in a task are under vars: indented under the task. Mixing these levels causes the variable to be unavailable in the wrong scope.

loop vs with_items. Modern Ansible uses loop: for iteration. Older playbooks use with_items:. If the JSON source uses an array for a repeated task, the converted YAML should use loop: with the array as its value.

How to Convert and Adapt the Output

Using the DevToolBox JSON ↔ YAML Converter to produce Ansible-ready YAML takes under five minutes.

1. Open the converter in your browser. No account, no install.
2. Paste the JSON task definition or variable file.
3. Select JSON → YAML conversion direction.
4. Review the output and apply Ansible-specific adjustments:
   • Wrap all Jinja2 template values in quotes: "{{ variable_name }}"
   • Verify boolean field names match Ansible module parameters
   • Check that vars blocks are at the correct indentation level
   • Replace with_items with loop for modern Ansible compatibility
5. Validate the resulting YAML with the YAML Validator before running the playbook.

DevToolBox tools run entirely in your browser — nothing you paste is transmitted to any server.

Common Conversion Errors

• Unquoted Jinja2 templates. This is the most common Ansible YAML error after conversion. Any {{ }} expression in a value that is not quoted causes a YAML parse error. The converter produces valid YAML, but valid YAML is not the same as valid Ansible YAML — Jinja2 expressions need the extra quoting step.
• yes/no vs true/false. YAML 1.1 (used by older Ansible versions) accepts yes, no, on, off as booleans in addition to true/false. JSON only has true/false. After conversion from JSON, the boolean values are true/false. This is correct for modern Ansible (which uses YAML 1.2 via yaml.safe_load), but may need adjustment for very old playbooks.
• Nested vars at the wrong level. A vars block placed inside a task body (under a module like package: or service:) is not the Ansible task-level vars — it is treated differently. After conversion, verify that variable declarations are at the correct structural level: play-level vars alongside hosts, or task-level vars alongside name.

Frequently Asked Questions

Conclusion

Converting JSON to Ansible YAML is mostly mechanical — the converter handles the structure — with one critical manual step: quoting Jinja2 template expressions that the YAML parser would otherwise misinterpret. After that adjustment and a syntax check, the converted playbook is ready to test. The alternative — rewriting the JSON by hand as YAML — takes longer and introduces the same indentation errors that YAML validation exists to catch.

If you need a fast JSON to YAML converter that produces Ansible-compatible output, DevToolBox does exactly that. DevToolBox tools run entirely in your browser — no signup, no install, nothing sent to a server.