NestedText is an indentation-based data format designed for people to enter, edit, and read directly. Unlike YAML and JSON, its leaf values are textual, while dictionaries and lists are represented through indentation and a small number of line tags. This converter takes a supported YAML data structure and emits the corresponding NestedText-style hierarchy. Mapping entries appear as key: value, list entries begin with -, and multiline strings are represented with lines beginning with >. The result is intended to be easy to inspect and edit by hand.
The distinction between structure and leaf values is important. A YAML number such as 8080 is represented as the text 8080 in NestedText output; the NestedText format itself does not declare that it is an integer. Likewise, a YAML boolean becomes the text true. This is a feature rather than a mistake: the NestedText model deliberately leaves application-specific interpretation of leaf strings to the consumer. When moving configuration back into a typed system, validate or convert those strings according to the schema that the application expects.
The converter uses a simple, readable indentation style and intentionally targets the common NestedText constructs that are useful for configuration. Objects become indented key blocks and arrays become groups of dash items. Multiline YAML strings are emitted as repeated > lines. This makes the result straightforward to compare with official NestedText examples, while avoiding claims that every advanced NestedText feature is being generated. In particular, the generated output should be viewed as a practical subset suitable for ordinary dictionaries, lists, and text values.
A useful learning exercise is to load the sample and compare the YAML and NestedText structures line by line. Notice that the hierarchy is still visible even though the markers are different. For lists, the dash becomes the structural cue. For nested objects, indentation is the main signal. This makes NestedText attractive for configuration that needs to be edited by people who prefer minimal punctuation. It also explains why consistent indentation remains important even in a format that is intentionally simpler than YAML.
The official NestedText format supports dictionaries, lists, multiline strings, and inline forms, and the generated output here focuses on the indentation-oriented forms that are easiest to read and round-trip with the bundled parser. The tool does not preserve YAML comments, anchors, aliases, or typed scalar syntax. All processing is local, and empty or malformed YAML is rejected before conversion.
NestedText is especially interesting when the reader matters as much as the machine representation. Its indentation makes dictionaries and lists easy to scan, while leaf values remain text. That makes it a useful educational comparison with YAML: both rely on indentation, but they make different choices about typing and punctuation. The generated result is intentionally straightforward so humans can edit it comfortably.
When reviewing a YAML-to-NestedText conversion, pay attention to scalars such as numbers and booleans. A YAML parser may treat 8080 as a number and true as a boolean, but NestedText records the leaf as text. The output therefore communicates the value rather than a type declaration. If another program consumes the NestedText, it must apply its own schema or conversion rules.
The generated syntax favors the indentation-oriented forms documented by NestedText: mapping items use a key and colon, lists use dashes, and multiline strings use greater-than lines. This makes the result readable without requiring inline punctuation. Advanced NestedText constructs are not necessary for many configuration files, so the tool stays focused on the subset it can serialize predictably.
A useful learning exercise is to convert the same small configuration in both directions and compare the trees. You will see that the hierarchy is preserved while the scalar typing model changes. This can help when teaching configuration formats, planning a migration, or deciding whether a human-edited settings file should use YAML, TOML, or a simpler text format.
Keep the original YAML when exact source preservation matters. Comments, anchors, aliases, and presentation choices are not carried into the NestedText data model. Similarly, a string containing syntax-like characters is emitted as literal text. The generated file should therefore be treated as a new representation of the configuration, not as a source-preserving rewrite.
The conversion remains local and deterministic, which is useful for private settings and reproducible examples. Empty input is rejected because there is no meaningful hierarchy to export. For ordinary nested mappings and lists, the writer is fast and produces a readable result that can be saved with an .nt extension for further editing.