INI / .properties ↔ JSON Converter

Features

• Both directions: INI → JSON and JSON → INI, detected automatically or set by hand
• One option switches dialect: INI ([sections], quotes stripped) or .properties (! comments, space separator, escapes, continuations)
• A `[db]` header becomes a nested object; the same section appearing twice is merged, not replaced wholesale
• Nesting beyond one level uses dotted section names (`[a.b]`), and each path gets exactly one header
• Duplicate keys keep the last value, and the overwritten keys are reported — that data really is gone
• `\uXXXX`, `\n` and `\: ` escapes plus backslash continuations are decoded the way Java does it
• Numbers convert only when lossless: `port = 5432` becomes a number, `zip = 007` stays a string
• `true` / `false` become booleans; `True` / `yes` stay strings (implementations disagree, so the tool does not guess)
• On output, values containing newlines, leading or trailing spaces, or starting with `#` `;` `!` are quoted so they cannot be read as comments
• JSON → INI reports nulls with their path (neither format has null)
• Parse errors name a specific location rather than saying “invalid format”

How to use

1. Paste INI / .properties or JSON — anything that parses as JSON is treated as JSON, the rest as INI
2. Check the dialect is right (pick the second option for a `.properties` file, or escapes and continuations will not apply)
3. The result updates as you type; the direction can also be set by hand
4. Copy the result

FAQ

Should I pick INI or .properties?

Follow where the file came from. A `.properties` file belongs to the Java world (`java.util.Properties`): it supports `\uXXXX` escapes, backslash line continuations and `!` comments, and quotes around a value are content, not delimiters. INI is the broader family (Windows `.ini`, various `.conf`): it has `[sections]`, and quotes do wrap values. With a `.conf` extension, look at the content — `[sections]` means INI, while `\u` escapes or a trailing backslash mean `.properties`. Picking the wrong one shows up as stray or missing backslashes and quotes, with no parse error.

Why did only one line survive when I wrote a key twice?

Because last-one-wins is the standard behaviour for both formats — Java’s `Properties` and nearly every INI reader work that way. This tool follows it, but reports the overwritten keys in the output, since that data really is lost. If you meant “this key has several values”, the conventional INI spelling is repeated keys, which readers handle individually — and that is what the export direction uses. The import direction keeps only the last one, so that path is lossy, and the tool says so.

What about arrays and nulls?

Neither format has arrays, and neither has null. An array is exported as repeated keys (`tags = a`, `tags = b`), the most common convention in the INI world. A null errors by default and names the key, because the alternative is the key vanishing entirely — you would get a config quietly missing a field, with nothing to tell you. You can also choose “as an empty value” or “skip the key”. ⚠️ A null inside an array cannot be skipped: removing an element shifts the index of everything after it, which is worse than an error.

Why is `port = 5432` a number but `zip = 007` a string?

The test is lossless round-tripping: a value becomes a number only if converting it to a number and back yields the original string. `5432` round-trips, so it becomes a number. `007` → 7 → `7`, which differs, so it stays `"007"` — the leading zero is part of the identifier and dropping it is irreversible. `true` / `false` become booleans (in a settings file, reading `debug = true` as the string `"true"` makes a downstream `if (cfg.debug)` always true), while `True` and `yes` stay strings, because implementations disagree on them and the tool will not guess. Pick “All as text” to disable inference.