XML to Properties Converter
Flatten XML into dotted .properties keys, choosing how attributes, repeated elements and namespaces are named — with duplicate keys flagged. All processing happens locally in your browser.
Flatten XML into dotted .properties keys
Each leaf element becomes one dotted key. Attributes, repeated elements and mixed content each need a naming decision, and all three are exposed as options rather than fixed.
configuration.server.port=8080
configuration.server.host=localhost
configuration.datasource.url=jdbc:mysql://localhost:3306/appdb
configuration.datasource.username=app_userEvery key is prefixed with the root element name "configuration". Turn on root dropping if your loader does not expect it.
What is the mapping from XML to dotted keys?
A .properties file is flat: one key, one value, per line. XML is a tree. Flattening one into the other means turning each path through the tree into a dotted key.
<configuration>
<server>
<port>8080</port>
<host>localhost</host>
</server>
</configuration>becomes
configuration.server.port=8080
configuration.server.host=localhostOnly leaf elements produce lines. An element that contains other elements contributes a segment to the key but has no value of its own, so it never appears on the left of an = by itself.
Note the root element name in every key. That is often unwanted — a Spring properties file would not normally repeat configuration on every line — so root dropping is available as an option.
How to convert
- Paste your XML Malformed XML is rejected with a line and column rather than producing partial keys.
- Choose how repeated elements are named Indexed keys keep every occurrence distinct. Comma style is compact but only works for simple values.
-
Decide where attributes go
As a child key, which reads naturally in Java, or with the
@prefix retained so they are unmistakable. - Check the duplicate-key warning A properties file cannot hold two identical keys, so a collision means data would be silently lost by the loader.
Repeated elements: where flattening genuinely struggles
This is the real difficulty. XML lets a name repeat; a properties file does not.
<servers>
<server><host>alpha</host></server>
<server><host>beta</host></server>
</servers>A naive flattener produces the same key twice:
servers.server.host=alpha
servers.server.host=beta ← the loader keeps only this oneThe first value is gone, silently. Indexed keys avoid it, and they match Spring's own relaxed binding so a List still binds correctly:
servers.server[0].host=alpha
servers.server[1].host=betaComma style is the other option, and works only when the repeated elements are simple values:
<roles><role>admin</role><role>editor</role></roles>
servers.roles.role=admin,editorIt breaks down as soon as a value contains a comma, which is why the tool warns when that happens. It also cannot express repeated elements that have children of their own.
The one-element trap applies here too. A document with a single <server> produces servers.server.host, with no index — because from one document there is no way to know the element can repeat. If the schema allows repetition, write the indexed form by hand so the key shape stays consistent across environments.
Examples: attributes and mixed content
An attribute has no natural place in a flat key, so it becomes another segment:
<book id="bk101" lang="en">The Pragmatic Programmer</book>With attributes as child keys:
catalogue.book=The Pragmatic Programmer
catalogue.book.id=bk101
catalogue.book.lang=enNotice that catalogue.book holds the element's text and acts as a prefix for its attributes. Java tolerates this — the keys are distinct strings — but it is worth knowing, because a strict binder expecting book to be a simple value may object to book.id existing alongside it.
Keeping the @ prefix removes the ambiguity at the cost of an unusual key:
catalogue.book=The Pragmatic Programmer
catalogue.book.@id=bk101Namespaces and escaped colons
A colon is a valid key/value separator in a properties file, so a namespace prefix has to be escaped:
<cfg:name>Prod</cfg:name>
root.cfg\:name=ProdWithout the backslash, a loader would read the key as root.cfg with the value name=Prod. Stripping namespace prefixes avoids the escape entirely and gives root.name, which is usually what you want unless two namespaces share a local name.
Empty elements and special characters
| XML | Property line | Reason |
|---|---|---|
<empty/> |
empty= |
An empty value, not null — properties has no null |
<flag enabled="true"/> |
flag.enabled=true |
No text, so only the attribute produces a line |
Value C:\temp |
path=C:\\temp |
Backslashes must be doubled in a properties value |
| Value with a newline | note=line one\nline two |
Newlines are escaped; a properties value is one line |
| Value starting with a space | pad=\ value |
Leading whitespace would otherwise be stripped |
What does not survive flattening
- Comments. A properties file supports them, but there is nowhere sensible to reattach an XML comment once the tree is flattened.
- The element-versus-attribute distinction. With attributes as child keys,
<a><b>x</b></a>and<a b="x"/>both givea.b=x. The flat form cannot tell you which it was. - Document order across branches. Keys are emitted depth-first, so siblings stay together but the original interleaving of different branches is not meaningful in a flat file.
- CDATA markers. The text is preserved; the marker is not.
- Types. Every value is a string, which is correct for a properties file — Java converts on binding.
- Namespace URIs. Declarations become ordinary keys such as
root.xmlns\:cfg, which is rarely useful. Ignoring attributes removes them. - Repeated keys. If two paths collide, only the last survives in the loader. The tool reports the collision so you can switch to indexed style.
Use cases
- Migrating legacy Spring XML configuration. Old
applicationContext.xmlsettings becomeapplication.propertiesentries that modern Spring Boot reads directly. - Producing environment variables. Dotted keys map mechanically to
SERVER_PORTstyle names, so the flat form is a useful intermediate step for containers. - Auditing a large XML config. A flat list of every setting is far easier to scan, diff and grep than nested markup.
- Comparing two environments. Flatten both and diff the property lines; nesting differences stop obscuring real value changes.
- Finding hidden settings. Attributes buried on deep elements are easy to miss in XML and obvious in a flat list.
- Feeding a key-value store. Consul, etcd and similar systems take flat keys, so this is the shape they need.
To go from the flat form into nested YAML, continue with Properties to YAML. For a structured rather than flat result, XML to JSON keeps the hierarchy, and JSON to Java generates the classes these properties bind to.
Privacy
Validation and flattening run entirely in your browser. The XML is not uploaded and no DTD or external entity is fetched. Usage analytics record only the array style, the line count and whether attributes were present.
Frequently Asked Questions
Why do I get duplicate keys, and does it matter?
It happens when an element name repeats, because two paths through the tree produce the same dotted key. It matters a great deal: a properties loader keeps only the last value, so earlier ones vanish silently. Switch to indexed array style to keep each occurrence distinct.
Should attributes keep the @ prefix?
Use a child key for Spring and most Java loaders, since @ is unusual in a properties key. Keep the prefix when you need to tell an attribute apart from a child element of the same name — with the prefix dropped, and x both produce a.b=x.
Why is there a backslash before the colon in my key?
Because a colon is a valid key/value separator in a properties file. A namespace-prefixed element such as cfg:name must be written root.cfg\:name, otherwise a loader reads the key as root.cfg with the value "name=Prod". Stripping namespace prefixes avoids the escape.
Can I remove the root element name from every key?
Yes, with the root dropping option. It is usually what you want: a Spring properties file would not normally repeat "configuration" on every line. Keep it when the consumer expects the full path, or when the XML has several top-level elements.
What happens to an element that has both text and attributes?
The text goes on the element's own key and the attributes become child keys, so book=Title sits alongside book.id=bk101. Java accepts this because the keys are distinct strings, but a strict type-safe binder may object to a key being both a value and a prefix.
Are values converted to numbers or booleans?
No, and that is correct. Every value in a properties file is a string; Java converts on binding. Writing port=8080 unquoted is exactly right, and there is no quoting or typing decision to make in this format.
My XML has one <server> but the schema allows several. What should I do?
Add the index by hand: servers.server[0].host rather than servers.server.host. From a single document there is no way to know the element can repeat, so the flattener cannot infer it. Getting this right keeps the key shape consistent across environments.