INI Validator
Check INI text for sections, key=value lines, comments, and duplicate names. It does not look for HTML tags.
🔒 Processed entirely in your browser — nothing you enter here is ever uploaded.
The result appears on this page after you run the tool. Nothing you enter is uploaded.
Result
About this tool
Paste the file and run the check. The scanner splits on newlines and trims each line. An empty line, or a line whose first character is # or ;, is skipped, so both comment styles are accepted and the rest of a comment is not parsed. A line that starts with [ and ends with ] is a section. The name is the inside, trimmed. An empty name fails with INI section name cannot be empty. The same section name a second time fails with Duplicate INI section found, and the line number is the second header. Opening a section clears the set of keys, so a key may appear again in a later section.
Any other line must contain an equals sign. The key is the text before the first equals, trimmed. An empty key fails. The same key twice inside the current section fails with Duplicate key and the key's name. The text after the equals is not interpreted: quotes, numbers, and trailing comments on the value are not checked. A line with no equals and no section brackets fails with Invalid INI row format. The success message is INI syntax is valid! The failure text in the box is STATUS: INVALID, the line, and the message. When a line number exists, the page also reprints two lines before and two lines after that line.
A file that passes this check can still be wrong for the program that reads it. The scanner does not require a section before the first key, so keys above the first header are allowed and they share one key set until a header appears. It does not expand ${variables}, does not join backslash continuations, and does not treat a semicolon in the middle of a value as a comment. Two sections with the same name are always an error here, even if some parsers would merge them. The older benefit line on this page talked about unclosed tags. This checker never looks at tags. That wording was copied from an HTML checker and does not describe this file. The result can be copied or downloaded as validation-passed.txt or validation-failed.txt. The text stays in the browser. A preset can fill the box and submit the form, which is why an example page can show a pass or a duplicate-key failure as soon as it loads. The checker is the loop above, not a third-party INI library, so a dialect it does not mention is a dialect it does not enforce.
Example. [app]\nname = demo passes. A second [app] fails with Duplicate INI section found. Inside one section, debug = 0 followed by debug = 1 fails on the second line with Duplicate key "debug".
Limit. Comments are only whole lines that start with # or ;. Values are not typed, continuations are not joined, and the checker does not look for HTML tags.
What does a valid INI line look like here?
A section is [name] with a non-empty name. A setting is key = value, and the value may be anything after the first equals. Blank lines are ignored. A whole line that starts with # or ; is a comment. The success text is INI syntax is valid!
Why did a repeated key fail?
Keys are tracked inside the current section. debug = 0 and later debug = 1 in the same section fail on the second line: Duplicate key "debug". A new [section] clears that set, so the same key may appear again under a different header. A repeated section name fails even if the keys differ.
Does it understand types, includes, or line continuations?
No. The characters after the equals sign are not parsed. A backslash at the end of a line does not join the next line. A semicolon that sits after a value is part of the value, because comments are only recognized when they are the whole trimmed line.
Will it flag an unclosed HTML tag?
No. There is no tag stack. A line that is not a section and has no equals sign fails as an invalid INI row. The report names the line and reprints a couple of lines around it.