Convert NDJSON to INI

The mismatch is total and it is worth naming before anything else. An INI file is a set of named sections, each holding flat key-and-value lines — a description of one thing, usually one application configuration. A newline-delimited JSON file is a sequence of records with no name, no order that means anything and no fixed length.

There is no representation that satisfies both. What the conversion does is use the only name a record in a list has, which is its index: the first line becomes [0], the second [1], and so on. That is faithful, it loses nothing, and it produces a file whose section names carry no meaning at all.

If the records are genuinely several configurations — one per host, one per environment, one per tenant — then renaming [0] and [1] to the names those things actually have turns the output into a usable file, and it is the whole job. The keys underneath are already correct.

If the records are data rather than configuration, no amount of renaming helps, and the numbered sections are the conversion telling you so. A hundred sections named after positions is not a configuration file; it is a table written in the wrong notation. CSV, JSON or a database is what that wants, and each of them is one conversion away from the same source.

This catches people, so it is worth being explicit. A file with exactly one line is still a list of one, and the output is a [0] section holding every field of that record. It is not the clean INI you would get from the same object on its own.

The fix is to change the source format rather than to edit the output. Save that single line with a .json extension and convert JSON to INI instead: there the record’s top-level keys become the section headers, plain values are written above them, and the file looks like something a person wrote. It is the same data through a different door, and it takes ten seconds.

INI supports sections and nothing inside sections. On this pair that single level is consumed by the record index, so every field of a record — including any nesting it had — has to live in the key name.

A record with a server object containing a port produces a line reading server.port inside the numbered section. Nothing is discarded and the path is preserved, but two records with the same nested structure now share nothing structurally: they are two sections whose keys happen to be spelled the same way. Any parser that rebuilds nesting from dotted keys will rebuild it per section, which is usually what you want and never something to assume.

A record carrying a list of allowed hosts produces keys named 0, 1 and 2 under the path of that field. Combined with the numbered sections, an output can end up with a line reading hosts.0 inside a section called [2], which is legible and unlovely.

INI parsers that support lists at all usually expect a single line with comma-separated values, and a few expect the same key repeated. Neither is what this produces. If the application has a convention, joining the array into one string in the source before converting produces a line the parser reads natively, and doing it afterwards means editing every group by hand.

A JSON true is written as true, a number as its digits, a null as the key with nothing after the equals sign, and a string exactly as it was. Quotes appear only where the value would not otherwise come back the way it went in: around a value with a space at either end, one that already starts and ends with a quote, and one containing a line break. That keeps the file looking like a file somebody typed, which is what anyone editing it afterwards expects.

A line break inside a value is the case worth naming, because an INI entry is a line. It is written as a backslash and an n inside the quotes rather than as a real break, which is what stops the text after it from becoming loose lines — or, when one of them looks like a bracketed header, a section that was in no record. Certificates, keys and embedded scripts are the usual carriers, and while they now survive a round trip here, a value of that size still belongs in its own file with the INI pointing at the path, which is what most applications that read INI expect anyway.

INI supports comments — a line beginning with a semicolon or a hash — and this site’s reader honours both in the other direction. JSON does not, so the converted file arrives with none.

Since the reason to produce an INI at all is nearly always that a person is going to read or edit it, writing those lines is the first useful edit. Which sections are environment-specific, which value has to match something elsewhere, and which the application ignores: none of that could be carried by the source and all of it is what the destination format is for.

Every value in an INI file is text. Whether 8080 is a number, whether true is a boolean and whether 007 keeps its zeros is decided by whatever reads the file — Python configparser makes it explicit with getint and getboolean, and accepts yes, on and 1 for true as well.

That is a loss relative to the source, where the types were written down. It is also not usually a problem, because an application reading INI already knows what it expects each setting to be. Where it does matter is identifiers with leading zeros, and the fix lives in the reading code rather than in the file.

The honest stopping rule for this pair: if the output has more than a handful of numbered sections and you cannot give each of them a real name, the conversion has answered a different question from the one you asked. INI describes one thing; a list of records is not one thing.

The alternatives from the same file are all a click away and all better for that case. CSV or a workbook if a person is going to look at the records, SQL or Parquet if a machine is going to query them, TOML if what you actually wanted was a list of records in a configuration file, since it has an array-of-tables construct that INI simply lacks.

The conversion is plain JavaScript in this browser tab. Nothing is uploaded, there is no account or queue, and the free tier accepts up to 100 MB — a limit no configuration file has ever reached.

It matters more than the file size suggests. Settings dumps hold connection strings, API endpoints, internal hostnames and, more often than anyone admits, a credential that was meant to be an environment variable. Sending one to a converter on somebody else’s infrastructure to have its braces removed would be a poor trade at any price.