INI to JSON

INI and JSON, and why you keep bouncing between them

INI files are everywhere old software lives. PHP’s php.ini, Git’s config, systemd units, Python’s setup.cfg, Windows desktop apps that never died. The format is dead simple to read by eye. But the moment you want to feed that config into a Node script, a CI pipeline, or anything that speaks JSON, you hit a wall. There’s no JSON.parse for INI.

That’s the gap this fills. Paste your INI on the left, get pretty-printed JSON on the right. It updates as you type, so you can tweak a value and watch the output shift in real time.

What the parser actually does

Here’s the breakdown of what gets handled:

• [section] headers become nested objects. A dotted name like [server.db] nests two levels deep, so server.db.port lands where you’d expect.
• Keys that sit above any section header (global keys) go straight on the root object. Plenty of real INI files start with a few loose settings before the first bracket, and those don’t get dropped.
• Comments starting with ; or # are stripped. But only when they’re real comments. A # inside a quoted value stays put, so password = "p@ss#1" keeps the hash.
• Quoted values keep their exact contents. Double quotes also decode \n, \t, \", and \\. Single quotes are taken literally.
• Bare values get typed. true, yes, and on turn into true. Numbers become numbers. 30.5 is a float, 8080 is an int, null becomes JSON null.

Everything runs locally. Your config never touches a server, which matters when half your INI files have database passwords and API tokens sitting in them.

A quick example

Drop this in:

title = "My App"
debug = true

[server]
host = localhost
port = 8080

[server.db]
password = "p@ss;word"  ; this comment goes away

And you get back:

{
  "title": "My App",
  "debug": true,
  "server": {
    "host": "localhost",
    "port": 8080,
    "db": {
      "password": "p@ss;word"
    }
  }
}

Notice port is a number, not a string. The semicolon inside the quotes survived. The trailing comment didn’t. That’s the whole point.

Things to watch out for

INI has no official spec, which means dialects disagree. This parser picks sane defaults, but a few cases are worth knowing.

Duplicate keys inside the same section overwrite each other, last one wins. If your dialect treats repeated keys as a list, you’ll lose the earlier entries. Multi-line values and line continuations with a trailing backslash aren’t supported either, so keep each value on one line. And a stray [section with no closing bracket throws a parse error pointing at the line number, rather than guessing what you meant.

For the reverse trip or other formats, the YAML JSON Converter and XML JSON Converter cover those data shapes.

Questions people ask

What happens to keys before the first section?

They become top-level properties on the JSON object. Global keys aren’t ignored or wrapped in a fake section, they sit right on the root.

Does it keep comments?

Nope. JSON has no comment syntax, so ; and # comments are discarded during parsing. Comments inside quoted strings are kept because they’re part of the value, not a comment.

Are values typed or left as strings?

Typed where it’s unambiguous. Booleans, integers, floats, and null get converted. Anything that doesn’t match those patterns stays a string, and quoted values always stay strings.

Why did I get a parse error?

Usually an unterminated [section header or a line that has no = sign. The message includes the line number so you can jump straight to it.

Is my config uploaded anywhere?

No. The parser is pure JavaScript running in your browser. Nothing gets sent over the network, which is why it’s safe for files holding secrets.