INI / Properties File Parser
How it works
INI → JSON reads lines starting with ; or # as
comments (skipped), blank lines as skipped, [name] as a section header that
starts a nested object, and key=value or key: value as a property —
trimmed on both sides, with a single pair of surrounding quotes stripped from the value if
present. Properties before any section header land at the root of the JSON. A line that isn't
blank, a comment, a section, or a recognizable key=value pair is a malformed line,
and produces an error naming which line.
JSON → INI writes root-level primitive keys as bare key=value
lines first, then each root-level object key as its own [section] block. Only
one level of nesting is supported — a nested object more than one level deep, or an array
anywhere, has no faithful INI representation and produces a clear error instead.
Frequently asked questions
What counts as a "section" in this format?
A line like [database] groups every key=value pair that follows it — up until the next section header or the end of the file — into a nested JSON object under the name "database". This is the standard INI convention; properties written before the first section header end up at the root of the JSON instead.
Why does JSON → INI only support one level of nesting?
INI is inherently a flat, two-level format: a document has root-level properties and sections, and a section holds only its own key=value pairs — there is no syntax for a section inside a section. So a JSON document with an object nested two levels deep, or an array anywhere, has no faithful INI representation, and this tool throws a clear error naming that instead of silently flattening or dropping data.
What happens to comments?
Lines starting with ; or # are skipped entirely when converting to JSON — JSON has no comment syntax, so there is nowhere for them to go. This is the same one-way loss the YAML ⇄ JSON converter already documents for # comments: stripped on the way to JSON, and simply absent if you convert back.