INI to JSON

Parse INI config sections and keys into JSON, keeping values such as 1.10 and 0755 exactly as written.

INI Input

or drop a file here

JSON Output

{
  "name": "ZeroServer",
  "debug": true,
  "server": {
    "host": "localhost",
    "port": 3000
  },
  "database": {
    "url": "postgres://localhost/db",
    "pool": 10
  }
}

Parsing INI configuration

INI files store settings as key = value pairs grouped under [section] headers. This parser turns each section into a nested JSON object and keeps top-of-file keys at the root. Lines starting with ; or # are comments; anywhere else, both characters are part of the value, so a value such as #fff is never cut short. A value becomes a number only when the number writes back as the same text, so 3000 is a number while 1.10, 0755 and a 20-digit ID stay strings, and only the exact words true, false and null change type. A section that appears twice is merged, and a key set twice keeps its last value, with a note under the output for each. It runs entirely in your browser.

Built and maintained by Meet Shah · Last updated 9 October 2026

What this tool is used for

Reading a legacy INI configuration into a service that consumes JSON.
Comparing two INI files by converting both and diffing the structured result.
Producing a JSON fixture from an existing configuration file.
Checking how a parser will interpret sections and duplicate keys.
Migrating configuration into a format with real types rather than strings.

Frequently Asked Questions

Is there a single INI standard?: No, and that is the root of every difficulty here. There is no specification — Windows .ini, Python configparser, PHP parse_ini_file and Git config all differ on comments, quoting, duplicate keys and whether nesting exists at all.
How are sections mapped to JSON?: Each [section] becomes a nested object. Keys before any section header are the tricky case: they belong to an implicit root, which some converters place at the top level and others under a DEFAULT key. This one uses the top level, and a [section] sharing a name with one of those keys is an error, not an overwrite.
Are values typed?: INI has no types — everything is a string. Converters that guess turn a version like 1.10 into 1.1 and a zip code 01234 into 1234. This one makes a value a number only when it writes back as the same text, so 3000 is a number but 1.10 and 01234 stay strings; only true, false and null change type.
What about duplicate keys?: Genuinely undefined. Python's configparser raises an error by default, Git config builds a list, Windows returns the first and PHP keeps the last. JSON cannot hold a key twice, so converters choose. This one keeps the last value and merges a repeated [section] into the first, with a note under the output for each.
Which comment character is correct?: Both ; and # are used, and support varies. Inline comments are the real problem — some parsers cut a value short at a ; even mid-value. This converter treats ; and # as comments only at the start of a line, so no value is cut, and a note flags a value that starts with one or has one after a space.
How should a key outside any section be handled?: As a top-level property, since INI allows values before the first [section]. Discarding them is a common bug, because many real files put their most important settings there.

Common errors and gotchas

Expecting types. INI values are strings, so true and 42 need converting deliberately rather than by hope.
Assuming one INI dialect. Comment characters, duplicate-key handling and nesting conventions all vary.
Losing comments, which JSON cannot represent and which often carry the only documentation.
Overlooking a duplicate key, where parsers variously keep the first, the last or build an array.
Treating a dotted key name as nesting when the source file meant it literally.