Updated · Built and checked by the PlinzoTools team, formulas tested against published sources
Convert .ini-style configuration files into JSON.
{
"server": {
"host": "localhost",
"port": "8080"
},
"database": {
"name": "mydb"
}
}INI files are a simple, widely used configuration format -- [section] headers grouping key=value pairs, with ; or # starting a comment line. This tool parses an INI file into a nested JSON object, one sub-object per section, with any keys before the first section header placed at the JSON root.
Paste .ini-style configuration text. The equivalent nested JSON structure appears instantly.
Each [section] line starts a new nested object in the output, keyed by the section name. Each key=value or key: value line inside that section becomes a property of that object. Lines starting with ; or # are treated as comments and skipped.
[server] converts to {"server": {"host": "localhost", "port": "8080"}}.
host=localhost
port=8080
For YAML configuration files instead, see the YAML to JSON Converter.
The converter reads the input line by line after trimming each line. Blank lines and lines beginning with a semicolon or a hash sign are skipped as comments. A line wrapped in square brackets starts a new section, which becomes a key in the root JSON object holding an object of its own. Any other line is matched as a key and value, split at the first equals sign or colon it finds. Both the key and the value are trimmed of surrounding whitespace. Keys that appear before the first section header are placed directly at the root of the JSON object.
Line "key = value" becomes "key": "value". Line "[name]" becomes "name": { ... }.
This is the most important thing to know before using the JSON in code. The converter does not guess types. A value such as 8080, true or 3.14 is written to the output as the string "8080", "true" or "3.14" with quotation marks. INI has no standard type system, so guessing would be unreliable, but it means your application must convert numbers and booleans itself after loading the JSON. If you need real numbers or booleans in the output, edit them in the JSON afterward or handle the conversion in your parser.
Imagine a hypothetical file with a section called paths and a line reading root: /var/www followed later by another line reading root=/srv/app in the same section. Both lines use different separators, but they share the key root, so the later one overwrites the earlier one and the JSON contains only the last value. The same applies to a section name that appears twice: the second occurrence starts a fresh, empty object and replaces the first, so entries from the earlier block are lost. If your INI relies on repeated keys to build lists, this converter will not preserve them.
Values that themselves contain an equals sign or colon are safe as long as the first separator on the line is the real one. For a line like url = http://host/?a=1, the key is url and the value is everything after the first equals sign. Be careful with keys that contain a colon, though, because the split happens at whichever separator appears first.
Yes -- INI has no native type system, so every value (including things that look like numbers) is kept as a string in the resulting JSON; convert types manually if your application needs numbers or booleans.
They're placed directly at the root of the resulting JSON object, matching how most INI parsers treat "global" settings outside any section.
Section names are used literally as JSON keys, so a dotted section name becomes one key containing a literal dot, rather than being split into nested objects.
INI files carry no type information, and the converter does not guess. Every value is output as a JSON string. Convert types in your own code or edit the JSON after conversion.
The last occurrence wins because each assignment overwrites the previous one. Earlier values with the same key are dropped from the JSON.
No. Only lines that start with a semicolon or hash are treated as comments. A comment at the end of a value line stays inside the value string, so move it to its own line first.
No. A section name is used as a single literal key, so a heading with dots stays one key containing the dots rather than becoming a nested structure.
Reference: MDN Web Docs