Converting NestedText to YAML is not merely a matter of changing a few punctuation marks. NestedText uses indentation, mapping tags, list tags, and textual leaves to represent a hierarchy. This tool first builds that hierarchy, then serializes it as YAML. A line such as server: / becomes a YAML mapping entry, an indented block becomes the child mapping or list, and a dash-prefixed item becomes a YAML sequence element. The approach makes the structural relationship explicit rather than attempting a line-by-line text substitution.
NestedText’s leaf-value model is the most important semantic difference to remember. If a source line says port: 8080, the parser treats the leaf as the text 8080. The generated YAML therefore quotes or preserves that value according to the serializer, and a later YAML parser may interpret it as a number. The same applies to values that look like booleans, dates, or nulls. This tool does not pretend that it can recover the application’s intended type from NestedText text alone; the consumer’s schema still matters.
The parser supports the common indentation-based forms generated by the companion YAML-to-NestedText tool. It recognizes mappings, lists, comments, and multiline strings introduced with >. Indentation must increase for a nested value and return to an earlier level when the block ends. If a line cannot be interpreted as a mapping entry or list item, the tool stops and reports the problematic line instead of silently treating it as a scalar.
A good workflow is to start with a clean configuration where keys are simple and indentation is consistent. Load the sample to see the expected shape, then replace it with your own content and convert. After conversion, inspect values that could be type-sensitive before handing the YAML to an application. This is especially important for identifiers with leading zeros, version strings, or values such as yes and no that some YAML parsers may treat differently depending on their rules.
The implementation intentionally supports a practical subset of NestedText rather than every advanced syntax feature. It preserves the major configuration-oriented constructs needed for round-tripping common mappings, lists, and multiline strings, but does not implement every inline or multiline-key feature from the full specification. NestedText is designed around dictionaries, lists, and strings with indentation as the structural signal, which is why the importer focuses on those forms. All processing remains local and the output can be copied or downloaded immediately.
The importer is designed around the core configuration-oriented NestedText model: dictionaries, lists, indentation, comments, and textual leaves. That makes it useful for common files produced by the companion exporter, while avoiding the false confidence of claiming complete support for every advanced NestedText feature. The UI intentionally keeps the controls simple because indentation is the main input signal.
Type handling is the main semantic decision. NestedText leaves are strings, so a line such as enabled: true arrives as the text true. The generated YAML can later be interpreted as a Boolean by a YAML parser, which is convenient for some migrations but potentially surprising for identifiers or version strings. Review those fields after conversion rather than assuming the original textual meaning is always obvious.
Indentation errors are more important than cosmetic spacing. A child value must be more indented than its parent, and the parser uses the indentation transitions to build the hierarchy. Keeping one consistent indentation width makes source files easier to reason about, even though the NestedText format is designed to infer nesting from any increase in indentation.
Comments are ignored because they do not belong to the resulting data tree. This is similar to YAML parsing, but it means a comment-only change will not appear in the generated YAML. If documentation is part of your configuration workflow, preserve the original NestedText file and treat the YAML as the operational representation.
For migration work, convert a small sample first and validate the YAML with your normal tooling. Once the shape is correct, process the larger file. This staged workflow makes it easier to spot a key that became a list, a string that became a Boolean-looking scalar, or a block whose indentation was inconsistent.
The importer stays entirely in the browser and reports malformed lines instead of skipping them. The supported subset is intentionally practical and matches the companion exporter, while more advanced NestedText syntax may require a dedicated implementation. The result can be copied or downloaded immediately for the next stage of your configuration workflow.