Convert INI to YAML

Each section header becomes a top-level key and its settings are indented two spaces beneath it. Keys written above the first section header stay at the top level alongside those blocks. The output uses spaces throughout — YAML forbids tabs for indentation, and a converter that emitted them would produce a file no parser accepts.

The result is a valid YAML document, not a fragment. That distinction matters when the destination is a values file or a variable set, because you will usually want the whole thing nested one level deeper under a key of your own, and it is easier to indent a known-good document than to reason about a fragment.

INI files say On and Off far more often than they say true and false. php.ini does it, Windows configuration does it, and dozens of daemons do it. The reader here does not treat those words as booleans, so they stay strings, and the writer emits them unquoted: engine: On.

Whether that line means a string or a boolean depends on which YAML your parser implements. YAML 1.2, the version the registry records for the format and the version the parser on this page implements, says it is the string "On". YAML 1.1 says it is boolean true, and PyYAML implements 1.1 — which means Ansible, and a long tail of Python tooling, will read that line as a boolean. The same applies to yes, no, y and n.

The fix is quoting, and it has to be done by hand because the converter cannot tell which of your On values were meant as switches. Write engine: "On" if you want the string in every parser, or engine: true if you want the boolean in every parser. Both are unambiguous under 1.1 and 1.2, which is the only property worth optimising for.

It is worth doing the pass deliberately rather than fixing the ones that break. A boolean read as a string is usually truthy and therefore silently on, and a string read as a boolean usually fails a schema check loudly — so the dangerous direction is the quiet one, where a setting you disabled comes back enabled and nothing fails until something does.

The typing happens while reading the INI, not while writing the YAML, so by the time the YAML writer runs the decision is already made. Values that parse as finite numbers become numbers and true and false become booleans; everything else stays a string.

Three cases in a config file come out changed. A version pinned as 1.0 becomes 1. A file mode written 0755 becomes 755, which is not the same mode. A hexadecimal mask written 0x1F becomes 31. Values with a unit attached are safe, so 128M stays 128M and 30s stays 30s, and so are addresses like 127.0.0.1 and times like 08:00, none of which parse as a single number.

A header written [tool.pytest] or [mail.smtp] becomes one key named exactly that, not two levels of nesting. The reader takes everything between the brackets as a single name, which is the only defensible reading — in php.ini, keys and sections alike are full of dots that are part of the name.

YAML accepts such a key unquoted, so the output is valid and reads fine. It is also not what a Helm chart or an Ansible role wants, where mail.smtp.host would normally be three levels. Splitting it is a manual edit and a deliberate one, because you are deciding something the source file never said.

Configs that were assembled by appending an environment overlay to a base file end up with the same section header twice. The reader creates a fresh empty section each time it sees a header, so only the last occurrence survives and the earlier one is dropped without a message.

This is worth checking before the migration rather than after, because the output is well-formed YAML that simply lacks settings, and a missing key in a deployment usually surfaces as a default silently applied rather than as an error. Search the INI file for duplicate headers first; the same last-wins rule applies to a key repeated inside one section.

YAML supports comments and INI supports comments, and none of yours survive this conversion. Comment lines are skipped during reading and nothing writes them back, so a file that was half explanation arrives as pure settings.

On a config that has been edited in place for years, those comments are the institutional memory: the note that a timeout was raised for one report, the block commented out during an incident and never removed, the initials and date next to a value nobody wants to touch. Copy the original INI file into the repository in the same commit as the YAML. It costs nothing and it is the only place that reasoning still exists.

The reader and writer are both plain JavaScript in this page, so the file is never sent anywhere. That is a general property of the data conversions here, and this pair is the one where it earns its keep: the INI file being migrated off an old server is very often the file with the database password, the SMTP credentials and the API keys in it.

The free ceiling is 100 MB, which no configuration file approaches. Practically the conversion is instant, and the only thing worth doing slowly afterwards is reading the output — because the moment those secrets are in a YAML file in a repository, they are in the repository history for good, and that is a decision to make before the commit, not after.

If the application still reads INI and always will, converting is churn. YAML buys you nesting, lists, comments in review and a linter, and none of that helps a program whose parser expects sections and equals signs. The migration is worth it when the config is moving into a system that reads YAML natively, not when the file merely looks old.

The other honest reason to stop is scale. A file with three sections and twenty keys is faster to retype into the target structure than to convert and then reshape, and retyping means you read every value once. Use the converter when the file is large enough that reading it by hand is the error-prone option.