INI to JSON

Parse INI config sections and keys into JSON.

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. Comment lines starting with ; or # are ignored, and values are coerced to numbers, booleans, or null where it makes sense. It runs entirely in your browser.

Built and maintained by Meet Shah · Last updated 28 July 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.
Are values typed?: INI has no types — everything is a string. Converters infer numbers and booleans, which introduces the same hazards YAML has: a version like 1.10 becomes 1.1, and a zip code 01234 loses its leading zero.
What about duplicate keys?: Genuinely undefined. Python's configparser raises an error, Git config treats repeats as a multi-valued list, and Windows takes the last. JSON objects cannot have duplicate keys at all, so the converter must choose.
Which comment character is correct?: Both ; and # are used, and support varies. Inline comments are the real problem — some parsers treat everything after a ; as a comment even mid-value, silently truncating a value containing one.
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.