Convert INI to XML

The mapping is direct enough to predict. A section header becomes an element, each key under it becomes a child element, and the value becomes that element text. An INI file holding [db] with host and port under it comes out as a db element containing a host element and a port element, indented two spaces per level.

That predictability is the reason this pair is worth a tool rather than a script. There is no ambiguity to resolve, because an INI file offers a converter almost nothing to interpret: one level of grouping, one key, one value per line. Everything interesting happens at the edges, and the rest of this page is those edges.

XML requires exactly one outermost element and an INI file has no concept of one. The converter resolves that by looking at what it read: if the file contained a single section and nothing else, that section becomes the root, so a one-section file named [settings] produces a document whose root tag is settings. Anything else — two sections, or keys written above the first section header — is wrapped in a generic root element.

This is worth knowing before you write an XSD or an XPath against the result. Adding a second section to the source INI file silently changes the root element of the output from settings to root, and every path expression written against the first version stops matching. If the document shape matters downstream, decide on the wrapper yourself and keep it stable rather than letting the section count decide it.

INI has no type system at all: everything to the right of the equals sign is characters. The reader guesses anyway, turning true and false into booleans and anything that parses as a number into a number, and the XML writer then prints whatever it got back out as text. For most keys the round trip is invisible.

For some it is not. A value written 007 is read as the number 7 and written back as 7. A version key written 1.0 becomes 1. A hexadecimal mask written 0x1F comes out as 31, and a Unix file mode written 0755 comes out as 755, which is a different mode. Anything with a unit attached survives intact, so 128M stays 128M, and so do dotted addresses like 127.0.0.1 and clock times like 08:00, because neither parses as a single number.

XML is far stricter about names than INI is. An INI key can contain spaces, slashes, colons and brackets; an element name can contain letters, digits, underscores, hyphens, dots and little else, and it may not begin with a digit. The writer therefore substitutes an underscore for every character it cannot use, and prefixes an underscore to any name that starts with something other than a letter or an underscore.

The substitution is not reversible, so two keys that differ only in punctuation collide into the same element name — "log level" and "log-level" do not, since the hyphen is legal, but "log level" and "log/level" both become log_level. If your INI file has keys like that, rename them in the source before converting rather than trying to work out afterwards which element came from which line.

A section header written [database.pool] looks like it should nest, and in TOML it would. Here it does not: the reader takes everything between the brackets as one section name, so the output holds a single element named database.pool with the keys inside it. Dots are legal in XML element names, so the document is valid; it is simply flat where you may have expected depth.

If the target schema wants real nesting, that structure has to be created rather than converted. The honest sequence is to convert first, then reshape the resulting XML with XSLT or by hand, because a converter that guessed at nesting from punctuation would guess wrong on every INI file where a dot is part of a name rather than a separator — and PHP configuration files, where keys like date.timezone are everywhere, are exactly that case.

INI has no standard, only conventions, and one of the places implementations disagree is what a repeated section header means. Some merge the two blocks. This reader does not: it creates a fresh empty section each time it sees a header, so a file with [logging] appearing twice keeps only the keys from the second occurrence and loses the first block entirely, without an error.

Repeated headers are rare in files written by hand and common in files assembled by concatenation — a base config with an environment overlay appended, which is a real deployment pattern. Search the source for duplicate headers before converting, because the failure is silent and the output is a perfectly well-formed XML document that is simply missing settings.

Both formats support comments. INI marks them with a semicolon or a hash, XML with an angle-bracket block, and this conversion carries none of them across: comment lines are skipped during reading and never reappear. The registry records both formats as comment-capable, which makes the loss an artefact of the pipeline rather than a limitation of the target.

On a configuration file that matters more than it sounds. The line above a timeout explaining that it was raised to 90 seconds because of one slow report is usually the only record of that decision anywhere. Copy the commented original into version control before converting, and reattach the explanations to the XML afterwards; nothing in an automated conversion of this kind can do it for you.

The reason to make this move is almost never the syntax. XML 1.0 has been a W3C recommendation since 1998, and around it sits the machinery INI never had: XSD schemas that reject a config with a misspelled key before the application starts, XPath for pulling one value out of a large document, XSLT for reshaping it, and XML digital signatures for asserting that a config file has not been altered.

None of that arrives with the conversion. The output is a well-formed document with no schema attached and no namespace declared, and writing the schema is the actual work — the conversion just gets you a starting document to write it against. If you do not intend to validate, sign or transform the result, the migration is buying you verbosity and nothing else.

If the application reading the file is the one that wrote it, and nothing downstream needs a schema, converting is a cost with no return. An INI file is editable by anyone who can open Notepad, and that is a genuine operational property when the person changing a setting at two in the morning is not a developer.

The conversion is also the wrong tool if what you actually need is two or three values out of the file rather than the whole thing. Read them out directly. This converter is for the case where the INI file is the config and the config is moving, not for extracting a fragment.