INI to JSON Converter – sections, keys and typed values

INI Input

JSON Output

Type values

The format with no specification

Somebody hands you a .ini, a .conf or a .cfg — a provisioning file for a SIM batch, a service settings file, a section of a php.ini — and you need it as data rather than as text. Maybe a script has to read it, maybe you are comparing staging against production, maybe you just want the nesting on screen instead of in your head. JSON is the shape most of those next steps want.

The catch is that INI has no specification. There is no RFC, no committee, no reference grammar — the format grew out of Windows 3.x and every parser since has implemented a slightly different dialect. Comments start with ; or with #, and some parsers accept only one of the two. Some read [a.b] as a section nested under a, others as a section whose name happens to contain a dot. Repeated keys are usually last-wins and always silent. None of that is a bug in anybody's parser; there is simply nothing to be right or wrong against.

Types are the second surprise. In INI everything is text — port = 5432 is the five characters 5432 until something converts it, which is why php.ini directives are documented with their expected types beside them. So this page defaults to the honest reading and leaves every value a string. Flip Type values on when you want numbers to arrive as numbers. true, false and null become JSON literals either way, because the widely-copied reference parser does that unconditionally and disagreeing with it would just make the output wrong somewhere else.

One more thing happens when you switch typing on, and it is the reason this page exists at all. A JavaScript number holds about fifteen reliable digits — MDN spells out the exact boundary — so a 19-digit ICCID handed to Number() comes back with its last four digits replaced by zeros. Typed conversion here protects the literal before it is parsed, so it lands in the JSON as a bare, exact integer. Most converters quietly round it and report success.

Converting a file

Paste your INI, or open the file – Upload reads the file in this tab and sends nothing anywhere, which matters when the config carries an API key. Sample loads a realistic provisioning file if you would rather see it working first.
Watch the JSON build as you type – Conversion runs about a third of a second after you stop typing. The chips above the output count the [sections] and the key = value lines that made it through, so you can check the file against what the parser found.
Decide whether you want types – Leave Type values off and every value stays a string, matching what the common parsers hand back. Turn it on and numeric literals become JSON numbers — useful when the JSON is going into something that will validate it.
Read the amber notice if one appears – It names duplicate keys, lines with no =, and a leading byte order mark. Those are the three ways an INI file reads one way to you and another way to a parser.
Copy or download – Two-space indented JSON. From there JSON to Table shows it as a grid, or JSON Formatter reindents it.

If the amber notice mentions a duplicate key, fix the file rather than the JSON. A repeated key is the nastiest INI bug going: the file reads perfectly to a human, every parser keeps the last value, and nothing anywhere reports it. INI Validator lists every one with its line number.

A provisioning file, and the value everything else destroys

Three things are worth watching. dns[] written twice becomes a JSON array — a convention the reference parser supports and plenty of others do not. mcc = 234 is the text 234 until you ask for typing. And iccid is 19 digits, which is past what a double can hold.

sim-provisioning.ini → sim-provisioning.json Type values on

sim-provisioning.iniSections, repeated key, comments

; provisioning defaults
[network]
mcc = 234
apn = internet
dns[] = 10.4.0.53
dns[] = 10.4.0.54

[sim]
iccid = 8901240544102066246
plan = Unlimited 5G

sim-provisioning.jsonArray from key[] · 19 digits intact

{
  "network": {
    "mcc": 234,
    "apn": "internet",
    "dns": ["10.4.0.53", "10.4.0.54"]
  },
  "sim": {
    "iccid": 8901240544102066246,
    "plan": "Unlimited 5G"
  }
}

When this is the page you want

Feeding an old config into something new

Plenty of long-lived services still read INI and plenty of new ones read only JSON. Converting once beats writing a parser for a format with no grammar to write it against, and the result drops straight into JSON Validator if the destination is fussy.

Diffing two environments

Convert both files and compare the JSON with JSON Diff. Section order, spacing around = and the choice of comment marker all stop mattering, so what is left is the difference that changes behaviour.

Checking what a parser will actually see

This is the one people underestimate. If a setting is not taking effect, converting the file shows you whether the key is where you think it is — inside the section you meant, spelled the way the service expects, and not quietly overwritten twenty lines further down.

Getting a config into a table

An INI file is a natural grid: section, key, value. INI to Table goes there in one step, and JSON to CSV takes the converted output further.

What it does

Both comment markers. ; and # are treated identically, including when one appears part-way along a value.
Repeated key[] entries collect into an array, instead of the last one overwriting the rest.
Duplicate keys are reported, not swallowed. Every parser tested keeps the last value and says nothing; you get the line number of both.
19-digit identifiers survive typed conversion — an ICCID or an account number comes out as a bare, exact JSON integer rather than a rounded one or a quoted string.
Nothing leaves the tab. The file is read and converted in your browser, so a config holding credentials never travels.

Questions that come up

Why is 5432 a string in the output?

Because in the file it is a string. INI has no type system, so the honest default is to hand back exactly what is written, which is also what most parsers do — the widely used ini package returns strings for everything except true, false and null. Turn Type values on when you want the conversion to make that judgement for you.

What happened to my comments?

JSON has no comment syntax, so there is nowhere to put them. That is a property of JSON rather than of this page — every converter drops them. If the comments are the valuable part, keep the INI and tidy it with INI Formatter, which rewrites the text and leaves every comment where its author put it.

My file has [database.primary]. Is that one section or two levels?

It depends entirely on the parser, which is the whole problem with dotted names. This page follows the reference behaviour and nests it, so you get database containing primary. A parser that does not will give you one section literally named database.primary. If the service reading the file treats it as flat, do not let the JSON convince you otherwise.

The first key in my file cannot be found by anything. Why?

Almost certainly a UTF-8 byte order mark. It renders as nothing at all, so the file looks perfect, but the first section header or key silently carries three extra bytes and every lookup for it misses. The notice under the output calls it out when it is there — it is one of the few INI bugs you genuinely cannot see.

Can I go back the other way?

Yes — JSON to INI, and the samples on the two pages are the same document, so you can paste one page's output into the other and get the original back. Values and structure survive the round trip; the comments do not, for the reason above.

Worth reading

Python configparser – The clearest write-up anywhere of the choices an INI parser has to make — interpolation, defaults, and which characters may separate a key from its value
RFC 8259 — the JSON specification – Eight pages of grammar, which is eight more than INI has ever had

INI to JSON