Properties converter

THE PRACTICAL GUIDE · NORMANDIN SYSTEMS

Get more from Properties converter

Properties converter converts Java properties or YAML to the alternative configuration format. Java properties commonly use dotted names for settings, while YAML can express a corresponding hierarchy. Dots in a properties key can be literal characters or an application convention for nesting. Escapes and duplicate keys need review. Check the selected conversion direction and compare each key after flattening or expanding a hierarchy. Use the worked example to understand what a successful result looks like, then compare it with a small sample of your own input. Keep the original available until you have checked the output in its destination. Conversion establishes a representation; it does not establish that the underlying information is correct or that the receiving application accepts every supported feature.

Guide updated October 13, 2026

How to use this tool

1. Enter or load Java properties or YAML using the input controls. Begin with the worked example or a small sample for which you know the expected result.
2. Review any available conversion options, then inspect the the alternative configuration format result. Resolve a reported parse error at its source before attempting to reuse the output.
3. Check the example below against your own data. Check the selected conversion direction and compare each key after flattening or expanding a hierarchy.
4. Copy or save the resulting the alternative configuration format content using the controls provided, then validate it in the application or parser that will actually consume it.

SEE IT IN PRACTICE

A worked example

app.name=Demo

app:
  name: Demo (when dotted keys are expanded)

The setting name and value remain meaningful while the file syntax and possible nesting change.

Literal keys and hierarchical keys

The key database.host may be a literal name in a properties file while becoming a nested database mapping in YAML. Whether that transformation is appropriate depends on the application. Test names containing dots, backslashes, spaces, and non-ASCII characters. Confirm that values survive escaping and that duplicate settings are resolved intentionally rather than silently lost.

Comments and repeated assignments

A properties file can contain comments and repeated assignments that make sense during manual maintenance but collapse when parsed into a mapping. Preserve explanatory comments separately if they document why a setting exists. For repeated keys, check which value survives rather than assuming both remain visible in YAML. After conversion, compare the resolved application settings as well as the file text, especially if dotted names control nested configuration.

When this tool is useful

• Prepare configuration format migrations while retaining a separate copy of the source.
• Use a small example to troubleshoot dotted-key and nesting differences and identify a representation mismatch.
• Create equivalent application-setting drafts without manually rewriting every field or symbol.

Tips for a better result

• Dots in a properties key can be literal characters or an application convention for nesting. Escapes and duplicate keys need review.
• Check the selected conversion direction and compare each key after flattening or expanding a hierarchy.
• After changing formats, compare meaningful values rather than whitespace alone. Read the the alternative configuration format output with its intended parser when exact types or escaping matter.

Frequently asked questions