Convert XML to INI

The flattening builds a dotted path to every value in the document, then splits each path once: the part before the first dot becomes the section, the rest becomes the key. An XML document has one root element, so that first segment is the same for every value in the file, and the output is one section with a long list of dotted keys under it.

That is worth setting expectations about, because it is not what the same conversion does from YAML or JSON, where several top-level keys give you several sections. If you want a section per logical group, the practical route is to convert the fragments separately — one conversion per child of the root — rather than expecting the tool to pick which level deserves a header.

Take the standard .NET shape: a configuration root, an appSettings element, and inside it several add elements each carrying key and value attributes. The output is a section headed configuration, and inside it keys reading appSettings.add.0.@key set to Timeout and appSettings.add.0.@value set to 30, then the same pattern with index 1 for the next entry.

It is faithful and it is not pretty. The information you actually wanted — Timeout is 30 — is spread across two lines that are related only by their shared index. If the destination is a script, it is usually less work to read the two lines and write Timeout=30 yourself than to teach the consumer this shape. The conversion is most useful when the XML has real element names holding real values, and least useful on the key-value-attribute pattern .NET favours.

Every attribute becomes a key segment prefixed with @, so an element with an id attribute contributes a key ending @id. An element that carries both attributes and its own text stores that text under a segment named #text, since the attributes have already taken the element key.

Neither prefix is a standard INI convention, and no INI parser will treat them specially. They are there so that nothing collides — an attribute named value and a child element named value would otherwise write to the same key — and they are the first thing to strip if the file is being handed to a program rather than read. Renaming keys in the output is safe; the INI has no structure left to break.

Two or more siblings with the same tag become an array during parsing and pick up numeric segments: add.0, add.1, add.2, in document order. Order is preserved, which is the part that matters for a rule list or a search path.

A single occurrence gets no number, because the parser had no way to know the element repeats — one add element is just an object. So the same config with one entry and with two produces different key names, and a script matching on appSettings.add.0.@key finds nothing on the day the file has a single setting. Write the consumer to try both, or normalise the keys after converting.

Two things in the output describe the XML rather than your settings. A document that opens with a version and encoding declaration produces a section headed ?xml holding those values, and any namespace declaration on the root becomes a key such as @xmlns inside the main section. Neither means anything to an INI consumer.

Delete both. A section header containing a question mark is legal in the sense that INI has no specification to violate, and it will still confuse the next person and possibly the parser reading it. The encoding value is also worth ignoring rather than trusting: an attribute reading 1.0 is parsed as a number and comes out as 1, so the declaration in the output does not even say what the original said.

A licence block, an embedded script or a formatted description is one element holding several lines of text, and an INI entry is one line. Until 2026-08-09 the writer emitted those newlines as they were, so every line after the first sat in the file with no key in front of it — discarded on the way back if it held no equals sign, and worse if it did: a line reading like a bracketed header opened a section that was in no XML document, and the next real setting was read back inside it.

The writer now wraps such a value in quotes and writes each line break as a backslash and an n, so the element stays one entry and comes back intact through this converter. It is still worth knowing which elements in the XML hold multi-line text, because the program you are feeding may read the backslash literally. Where that program matters, put the block in its own file and let the INI carry the path to it.

More than you would expect. Values keep their semicolons, their slashes, their spaces and their embedded equals signs, because INI parsers split at the first equals sign only — so a connection string reading Server=db;Database=x survives as a single value and reads back correctly.

Element order is preserved throughout, and so is the relative position of attributes and children. Numeric-looking values are parsed on the way in, which is where the exceptions are: a version attribute written 1.0 becomes 1 and a zero-padded identifier written 007 becomes 7. Anything you were treating as an opaque token is worth checking in the output.

Comments are dropped, and on a settings file that is usually the most valuable text present. Namespaces stop meaning anything once the prefixes are just characters in a key name. The distinction between an attribute and a child element survives only as an @ in a string. Nothing in the INI can be validated, because INI has no schema language at all.

That is the honest summary of the direction: XML has been a W3C recommendation since 1998 and carries schemas, XPath, transformations and signatures; INI has been around since 1985 and carries nothing but lines. Converting one way loses all of it and there is no path back, so the XML original belongs in version control regardless of what happens to the INI.

A great many people arriving at this pair want a handful of settings, not a flattened document. If that is the case, read them out of the XML and type them into the INI file in the shape the consuming program expects. It takes minutes, the result is legible, and none of the artefacts above appear in it.

Use the converter when the file is large enough that reading it by hand is where the mistakes come from, or when you want a complete inventory of what a vendor config contains before deciding which parts matter. Both are good reasons. Converting an XML config wholesale and shipping the result as the new settings file is not.