INI Overlay Merger
Merge an INI config with one or two overlay files — the way a deployment layers defaults, environment and local settings. Overridden values are edited in place, so the base file's comments, blank lines, key order and indentation all survive, and a change report shows exactly which keys were added, changed or left alone.
Input
The defaults. Its comments, ordering and formatting are what the merged output keeps.
Applied on top of the base — only the keys it names are touched.
Applied last, so it wins over the first overlay. Leave blank for a plain two-file merge.
Options
An inline comment sitting on a key's own line is always kept, even when this is off.
Output
| Section | Key | Base value | Merged value | Change |
|---|---|---|---|---|
| No data yet | ||||
Guides
What this tool does
Most INI-based projects keep one file of defaults and one small file per environment: app.ini plus production.ini, or defaults.ini → staging.ini → local.ini. Resolving those layers by hand is where mistakes creep in — a key gets missed, or a stale value from the base survives into production.
This tool applies an overlay on top of a base INI and shows you the resolved file, plus a report of exactly which keys it added, changed or left alone.
Most merge tools round-trip both files through an object and re-serialise the result, which quietly destroys every comment and reorders your keys. This one doesn't. It edits values in place in the base file, so comments, blank lines, key order, indentation — and even a trailing inline comment on the very line being overridden — all survive the merge. The output is a file you can commit.
How to use it
- Paste the base INI (your defaults) into the first box.
- Paste the overlay — the environment-specific file — into the second.
- Optionally add a second overlay. It is applied last, so it wins over the first:
defaults → environment → local, in the order deployments actually resolve them. - Read the Changes table, then copy or download the merged INI.
Everything happens in your browser. Neither file is uploaded.
Settings
- Keys only in an overlay — Add them (default) appends a key the base never declared to the end of its section, creating the section at the end of the file if needed. Ignore them merges only keys the base already declares, which is what you want when the base is the authoritative schema and a typo in an overlay should not silently invent a setting.
- Keep the base file's comment lines and blank lines — on by default. Turn it off for a compact, comment-free resolved file. Inline comments attached to a key's own line are kept either way.
- Match section and key names case-insensitively — some INI parsers fold case, some don't. Turn this on when your overlay writes
[Server]and the base writes[server]and you want them treated as the same section. - Assignment style for added keys —
key = valueorkey=value, for newly added lines. Existing lines keep whatever spacing the base used.
The change report
Every key an overlay touched appears in the table with its base value, its merged value, and one of four verdicts:
- Changed — the overlay replaced a different value.
- Unchanged — the overlay set the value the base already had. Usually a sign the overlay has drifted and that line can be deleted.
- Added — the key existed only in an overlay and was appended.
- Ignored — the key existed only in an overlay and Ignore them was selected, so it is not in the output.
What about [section.subsection] names?
Dotted section headers are treated as one literal section name, matching key-for-key across files. That is the safe reading for a merge — nothing is restructured. If you want dotted headers expanded into a nested object instead, run the result through the INI to JSON Converter.
Can I merge more than three files?
Merge the first three, then paste the result back into the base box and add the next overlay. To compare two configs rather than combine them, Text Compare gives a line-by-line diff.