JSON to INI

Serialize a JSON object into INI config format.

JSON Input

or drop a file here

INI Output

name = ZeroServer
debug = true

[server]
host = localhost
port = 3000

[database]
url = postgres://localhost/db
pool = 10

Serializing JSON to INI

This converter writes top-level scalar properties as global key = value lines and turns each nested object into its own [section]. Arrays are flattened into comma-separated values. INI only supports one level of nesting, so deeply nested JSON is best flattened first. The conversion is performed entirely client-side.

Built and maintained by Meet Shah · Last updated 28 July 2026

What this tool is used for

Producing an INI configuration for a legacy tool from a JSON source of truth.
Generating a config file for software that only reads INI.
Converting settings for a Windows application from a structured source.
Producing a flat, human-editable config from nested JSON.
Migrating configuration into an older format during a downgrade.

Frequently Asked Questions

What is lost converting JSON to INI?: A great deal, because INI is strictly two levels. Arrays have no representation, deep nesting must be flattened into dotted keys, and every type collapses to a string — so the round trip back is not guaranteed.
How is deep nesting handled?: By flattening into dotted section names or dotted keys, since INI supports [section] and nothing below it. A three-level JSON object becomes something like [a.b] with key c — readable, but no longer structurally the same document.
How are arrays represented?: There is no standard, which is why converters disagree: indexed keys (item.0, item.1), repeated keys, or a comma-joined string. All three are lossy in different ways, and the consumer must know which was used.
Do values need quoting?: It depends on the parser, which is the hazard. Values with spaces are usually fine unquoted, but a leading or trailing space, a semicolon, or a newline require quoting that not every INI reader supports.
Should I convert to INI at all?: Only when a legacy consumer requires it. TOML was designed as the modern answer to exactly this problem — it has a real specification, genuine types and array support — so new configuration should target TOML instead.
How should a key containing a dot be handled?: It has to be escaped or rejected, because dots are the usual flattening separator — `{"a.b": 1}` and `{"a": {"b": 1}}` would otherwise produce identical INI, which makes the conversion irreversible.
What happens to a null value?: INI has no null, so it becomes either an empty value or an omitted key, and the two mean different things to most readers. Deciding which is a real choice, not a formatting detail.

Common errors and gotchas

Assuming deep nesting maps cleanly. INI has one level of sections, so anything deeper needs flattening.
Losing types, since INI values are strings and a boolean or a number becomes text.
Producing keys containing characters the target INI parser treats as delimiters.
Flattening arrays into repeated keys, which parsers handle inconsistently.
Expecting comments in the output, when the JSON source had nowhere to hold any.