Convert JSON to INI

That sentence is the whole conversion. An INI file is a list of sections, each holding flat key-and-value lines, and there is no way to put a section inside a section. It has no specification — it dates from 1985, predates the idea that a config format would need one, and every parser has slightly different opinions about quoting and comments — which is why the registry marks it as legacy rather than current.

JSON nests without limit. So the conversion has to project a tree onto two levels, and the interesting question is not whether it works but what it does with the third level and everything below it. The short answer is that it keeps the data and gives up the structure, which is the right trade in the direction a config file usually travels.

Every top-level key whose value is an object becomes a section: a JSON file with server, logging and database objects produces [server], [logging] and [database], with the keys inside each written underneath. For settings that were written by a person in the first place, this is very often an exact match, and the output is the file you would have typed.

Top-level keys holding a plain value — a debug flag, a version number — are written above the first section header rather than after it. That is not a stylistic choice: an INI section owns every line that follows it until the next header, so a bare key written lower down would become a member of whichever section preceded it and change meaning.

A third level of nesting is written as a dotted key. If server holds a tls object holding a cert path, the output is a [server] section containing a line reading tls.cert. Nothing is discarded, and the path back to the original shape is written into the key name.

Some parsers understand that convention and rebuild the nesting; most do not, and treat tls.cert as a key that happens to have a dot in it. Either is usually fine for reading a setting. What it is not is round-trippable in general — a JSON key that genuinely contains a dot becomes indistinguishable from one level of nesting, and no reader can tell which it was.

The key survives and the value does not: a null comes out as the key, an equals sign and nothing. That is the closest INI has to an unset value, since the format has no null and no way to express one.

What your parser does with it varies, and it is worth ten seconds to find out. Python configparser returns an empty string. Some readers return the empty string too but treat it as false in a boolean context, and a few skip the key entirely. If the difference between "set to nothing" and "not set" drives behaviour in the application, delete those lines by hand rather than shipping the ambiguity.

INI has no list. An array of three allowed hosts becomes three lines keyed 0, 1 and 2, which preserves every value and matches almost no parser convention. The formats that do support lists usually expect one line with the values separated by commas, and a few expect the same key repeated.

This is the one part of the conversion worth changing in the JSON before you run it rather than in the INI afterwards. Join the array into a single string with whatever separator the application expects, convert, and the output is a line the parser reads natively. Doing it in the other order means editing every numbered group by hand.

A top-level JSON array produces sections named after array positions: [0], [1], [2], each holding the keys of one record. The file is syntactically valid INI and there is no sensible program that reads it.

That output is a signal rather than a failure. INI is a configuration format — a set of named settings for one application — and a list of records is data. If what you have is a list, CSV or a spreadsheet is the target if a person will read it, and JSON or a database if a program will. The conversion does not refuse, because a single-record file is a legitimate thing to want, but a run of numbered sections means the answer to the original question was no.

Almost every value is written exactly as it stands — a path, a hostname, a port, a flag — which keeps the file looking like a file somebody typed. Three kinds of value are not. A value containing a line break, a value that already begins and ends with a quote, and a value with a space or a tab at either end are wrapped in double quotes, and inside those quotes a line break is written as a backslash and an n, a carriage return as a backslash and an r, and a backslash as two backslashes.

That escape is recent and it replaced a real defect. Until 2026-08-09 a JSON string containing a newline was written through as a genuine line break, so the JSON {"app":{"motd":"hello\n[admin]\npassword=secret","plain":"x"}} produced an [admin] section that appears nowhere in the source — and the key written after it, plain, was read back inside that invented section rather than in app. A value could move its neighbours. Both halves of this converter now agree on the escape, so a multi-line value survives the round trip. A different program reading the file may not understand the escape and hand you the two characters back instead of a line break, so a certificate or an embedded script still belongs in its own file with the INI pointing at the path.

INI stores everything as text. A JSON true is written as true, a JSON 8080 as 8080, and what those mean afterwards is decided by whatever reads the file. Python configparser makes this explicit with getboolean and getint, and it accepts yes, on and 1 for true as well.

It is worth knowing which direction the guessing goes in your parser before relying on a value. A version string of 1.0 is text in the JSON and will very likely be read back as a number, and a build identifier with leading zeros loses them the moment anything treats it as an integer. Where that matters, the fix is in the application reading the file rather than in the file.

The output carries no comments, because JSON has none to give. INI does support them — a line starting with a semicolon or a hash — and this converter honours both when reading in the other direction.

Since the point of moving settings into INI is usually that a person is going to edit them, the comment lines are worth adding immediately: which values are environment-specific, which one has to match a value elsewhere, and which section the application ignores entirely. That is exactly the information a generated JSON file could never hold.

It is plain JavaScript in this browser tab. The file is not uploaded, there is no account or queue, and the free tier accepts up to 100 MB, which is several orders of magnitude more than any configuration file.

The privacy point is not decorative for this pair. Settings files hold database connection strings, API endpoints, internal hostnames and, more often than anyone admits, a password that was supposed to be an environment variable. Converting one on a server somewhere means handing all of that to a third party for no benefit at all.