INI Validator

The bug INI parsers refuse to mention

Set the same key twice in an INI file and nothing happens. No error, no warning, no line number. The npm ini package keeps the last value and returns; measured against js-ini, so does that one. MySQL documents the behaviour outright for its option files — if an option is given more than once, the last occurrence wins — which is honest, and still means a 400-line my.cnf can contain a setting that does nothing at all with no way to see it.

That is the difference between reading a config and running it. You scroll to max_connections = 200, satisfied. The server read the max_connections = 60 forty lines below it. Nobody wrote either line wrong; somebody merged two files, or added a block at the bottom during an incident and never came back. This page reports both lines with both line numbers, which is the single most useful thing a tool can say about an INI file.

The rest is the same category of problem: things every parser accepts and no two parsers agree on. A line with no = becomes the boolean true in one implementation and disappears in another. A header written [network without its bracket is not a header at all. A byte order mark saved by a Windows editor makes the first key three invisible bytes longer than the one your code looks up, which is a genuinely miserable afternoon if you have not met it before.

Errors are shown in red and warnings in amber, and the distinction is deliberate. Red means a line will be read as something other than what it looks like, or dropped. Amber means every parser agrees on what it means but the file probably is not saying what its author intended. A duplicate key is red, because the value you can see is not the value in play.

Using it

1. Paste or upload the file – Anything INI-shaped: .ini, .conf, .cfg, a tox.ini, a pip.conf, a copied .gitconfig. Checking runs as you type.
2. Read the errors first – Each one names its line, echoes the line back so you can match it against your editor, and says what to do about it. The line is highlighted in the pane on the left.
3. Then read the warnings – A warning is not a bug in itself. It is a place where the file is ambiguous enough that two tools reading it could reasonably reach different answers.
4. Check the summary – Sections, keys and comments, counted from the source. A key count lower than you expected usually means duplicates collapsed — which the error list will already have told you about.

Line numbers here count blank lines, so they match your editor exactly. That sounds obvious and is not: the reference parser splits on /[\r\n]+/, which collapses runs of newlines, so every position after the first blank line drifts. A validator whose line numbers are approximately right is worse than one that reports nothing.

A duplicate key, and what it costs

The file below is what a hand-merge produces. It parses cleanly in every tool tested, and the connection pool it configures is not the one anybody reading the file would expect.

; merged from staging and production
[pool]
maxConnections = 200
idleTimeoutMs = 30000

[pool]
maxConnections = 60

Error — line 7
maxConnections = 60
"maxConnections" was already set on line 3.
Every parser tested keeps the LAST value and
reports nothing, so line 3 is silently dead.

Warning — line 6
[pool]
Section [pool] was already opened on line 2.
Keys below here land in the earlier section.

When you would use it

A setting that refuses to take effect

You changed it, you restarted, nothing moved. Before blaming the cache, check whether the key is set again lower down. This is by far the most common cause and takes five seconds to rule out.

After merging two configs

Duplicate keys and repeated section headers are exactly what a hand-merge produces. Neither is an error to any INI parser, so nothing downstream will ever tell you.

Reviewing a config you inherited

A pip.conf or a tox.ini that has been edited by six people over three years accumulates dead lines. pip reads several config files in order, so a stale key in one of them is easy to miss and awkward to debug.

Before shipping a generated file

If something in your build writes an INI file, a validation pass catches the case where a template emitted the same block twice. Once it is clean, INI to Table is a quick way to eyeball what it actually contains.

What it checks

• Duplicate keys within a section, with both line numbers — the check no INI parser performs.
• Repeated section headers, which merge into the earlier section rather than starting a new one.
• Unclosed and unnamed headers — [network and [] are both flagged.
• Lines with no =, where parsers genuinely disagree about whether the setting exists.
• A UTF-8 byte order mark ahead of the first line, which no editor shows you.
• Exact line numbers, counted over the original text with blank lines intact.
• Nothing is uploaded. A config with a password in it stays in this tab.

Questions people actually ask

Is a duplicate key really an error? Nothing crashed.

Nothing crashes, which is the problem. Every parser measured keeps the last value silently, so the file states one thing and the program does another — and the only way to notice is to read the whole file carefully or to be told. It is marked as an error here because the value you can see on screen is not the value in effect.

Which INI dialect does this validate against?

There is no INI standard, so "valid" is defined by what the common parsers do rather than by a document. The rules here follow the widely used npm ini package: ; and # both begin comments, a backslash escapes them, a key[] suffix collects repeated values into a list, and everything is a string. Where two popular parsers genuinely disagree, that is reported as a warning instead of being silently resolved one way.

Why is a repeated section only a warning when a repeated key is an error?

Because they have different outcomes. Reopening [network] later in the file merges the new keys into the existing section — nothing is lost, and the result is usually what the author wanted anyway. A repeated key throws a value away. Same shape of mistake, very different cost.

My key[] lines are repeated and nothing is flagged. Why not?

The [] suffix means "this key holds a list", so repeating it is the point rather than a mistake. Repeats are collected into an array. Drop the brackets and the same lines become a duplicate key, with only the last one surviving.

Does .editorconfig count as INI?

Close enough to check here. EditorConfig uses INI-format sections with glob patterns as headers, so duplicate-key and unclosed-header detection apply exactly as they would to any other config. The glob semantics inside the brackets are its own business, not something this page interprets.

It says no problems found. Does that mean my config is correct?

It means the file says what it looks like it says. Whether apn = internet is the right value for your network is a question about your system, not about the file — a validator can tell you the config is unambiguous, never that it is right.

Related tools

Worth reading

• GetPrivateProfileString (Win32) – The API that made INI ubiquitous, and the closest thing the format has to an original definition
• tox configuration reference – A large, real INI file with sections that are meant to repeat — useful for seeing where the format bends