Converting Between Data Formats

Sometimes data arrives as a string that’s actually structured data in disguise — a registered command’s output that happens to be JSON, an API response captured into a variable. This chapter covers moving between a real Ansible variable and its JSON or YAML string representation, in both directions.

Why Convert Formats At All?

Two directions, two reasons: parsing a JSON or YAML string into a real list or dictionary you can actually work with (from_json, from_yaml), and serializing a variable you already have into a JSON or YAML string — useful for readable output now, and for writing to a file once file-handling modules enter the picture later in this course (to_json, to_yaml).

to_json And from_json

vars:
  person:
    name: Alice
    age: 30
tasks:
  - name: Convert to a JSON string
    ansible.builtin.debug:
      msg: "{{ person | to_json }}"

{"name": "Alice", "age": 30}

Notice the result is now a string — that entire thing is one piece of text, not a dictionary you could access with person['name'] anymore. Going the other way:

vars:
  json_string: '{"name": "Bob", "age": 25}'
tasks:
  - name: Parse the JSON string
    ansible.builtin.debug:
      msg: "{{ json_string | from_json }}"

{"name": "Bob", "age": 25}

This time the result is a genuine dictionary again — {{ (json_string | from_json)['name'] }} would correctly give you Bob.

to_yaml And from_yaml

Same idea, YAML instead of JSON:

msg: "{{ person | to_yaml }}"

{name: Alice, age: 30}

from_yaml parses a YAML-formatted string back into a real structure, exactly the way from_json does for JSON.

Pretty-Printing With to_nice_json And to_nice_yaml

to_json/to_yaml produce compact output — fine for machine consumption, harder to read at a glance. to_nice_json and to_nice_yaml add proper indentation:

msg: "{{ person | to_nice_json }}"

{
    "name": "Alice",
    "age": 30
}

A Practical Use: Inspecting A Complex Structure

to_nice_json is often a clearer way to look at a large, deeply nested structure than debug’s raw var: dump — worth remembering the next time you want to actually read through something like ansible_facts:

- name: Pretty-print all facts
  ansible.builtin.debug:
    msg: "{{ ansible_facts | to_nice_json }}"

A Gotcha: from_json/from_yaml Fail Loudly On Invalid Input

If the string genuinely isn’t valid JSON (or YAML), parsing it simply fails:

vars:
  bad_json: "not valid json"
tasks:
  - name: This fails
    ansible.builtin.debug:
      msg: "{{ bad_json | from_json }}"

This is worth remembering specifically when the string came from somewhere you don’t fully control — a registered command’s output, for instance. A command that normally returns clean JSON might instead print a plain-text error message the one time it fails, and from_json on that unexpected output won’t degrade gracefully; it errors immediately. If you’re parsing output from an external source that isn’t guaranteed to always succeed, that’s a real failure mode worth being aware of, even without full error-handling techniques (which come later in this course) to address it yet.

Best Practices

• Use from_json/from_yaml when you’ve captured structured data as a string — most commonly from a registered command’s output or an API-style response — and need to actually work with it as a real list or dictionary.
• Use to_nice_json/to_nice_yaml for readable debug output, especially on anything deeply nested, rather than a raw var: dump.
• Don’t assume external output is always valid JSON just because it usually is — a command that fails or misbehaves may hand from_json something it can’t parse at all.