INI to Table ViewerINI to Table
Nothing to show yet
Paste an INI file on the left. Every key under every [section] becomes a row.
Why a config is easier to read sideways
An INI file is a list of settings pretending to be a document. You read it top to bottom because that is how it is written, but the question you usually arrived with — where is the timeout set, and to what — is a lookup, not a read. Three hundred lines of php.ini answer that question badly. A grid you can sort by key and filter by substring answers it in about two seconds.
Each row here is one setting: the section it lives under, the key, and the value a parser would actually hand your program. That last part matters more than it sounds, because a key repeated inside the same section does not produce two rows. Every INI parser worth naming keeps the last one and says nothing about it, so the table shows the value that wins. If you want to know that the earlier line existed at all, INI Validator is the page that tells you.
There is no INI standard to point at — no RFC, no committee, just a shape everyone agreed on informally, which the Wikipedia article on INI files documents about as well as anything can. That is why PHP, git-config and Python configparser all read slightly different dialects of the same file. The reading here follows the widely used npm ini package: ; and # both start comments, an unescaped one ends a value, and a key[] suffix collects repeats into a list.
Values are text in INI — there are no types — so qci = 9 is the string "9" until something converts it. The table converts what unambiguously looks like a number so that a numeric column sorts numerically, with one deliberate exception: anything too long for a JavaScript double keeps every digit as written. A 19-digit ICCID displays as 8901240544102066246 here, not the rounded 8901240544102066000 that Number() would give you.
Using it
- Paste the file – Any INI-shaped config — .ini, .conf, .cfg, a tox.ini, a my.cnf, a copied .gitconfig. Or press Sample for a realistic one. The table rebuilds as you type.
- Sort by the column you are asking about – Sort on Key when you know the setting name and not the section. Sort on Section to read one block at a time with the rest out of the way.
- Filter to the setting you want – The search box matches across all three columns, so typing "timeout" finds the key, and typing "true" finds every flag that is switched on.
- Take it somewhere else – Use INI to JSON when you need the nested shape rather than a flat list, or INI Formatter to tidy the file itself.
Keys written above the first [section] header are real settings, not a mistake — they belong to an unnamed global section, and they show here under (no section) rather than being quietly dropped.
One provisioning file, one row per setting
A SIM batch profile with four sections. Note the iccid: nineteen digits, every one of them still there, and pin1 keeps its leading zero because a zero-padded code is not a number.
; SIM batch provisioning profile [sim] iccid = 8901240544102066246 imsi = 234150999912345 pin1 = 0482 [network] mcc = 234 apn = internet roaming = true
| Section | Key | Value |
|---|---|---|
| sim | iccid | 8901240544102066246 |
| sim | imsi | 234150999912345 |
| sim | pin1 | 0482 |
| network | mcc | 234 |
| network | apn | internet |
| network | roaming | true |
When this is the tool you want
Finding a setting in a file you did not write
A php.ini is thousands of lines and mostly commented-out defaults. Sorting by key turns "is memory_limit actually set anywhere" from a scroll into a glance.
Comparing two environments
Open staging in one tab and production in another, sort both by Key, and the rows line up. It is a poor substitute for a real diff, and a very fast one when you only care about four settings.
Reading someone else's tox.ini or setup.cfg
Python packaging leans on INI heavily — tox.ini, setup.cfg, pytest.ini. Seeing the sections as a column makes it obvious which tool owns which block.
Checking what a parser will really see
The table shows resolved values, so if a key is set twice you see the winner. That is usually the fastest way to explain why a config that "clearly says 30" behaves like it says 5.
Questions people actually ask
A key appears twice in my file but only once in the table. Is that a bug?
No, and it is the single most useful thing to understand about INI. Repeat a key inside a section and every common parser keeps the last value and reports nothing — so the file reads one way to you and another way to the program. The table shows what the program gets. To see both lines and their line numbers, run the file through INI Validator, which flags duplicates explicitly.
What happens to my comments?
They are counted and then left out, because a table has nowhere sensible to put them. Your input is never rewritten. If you want a tidy-up that keeps every comment exactly where it was, INI Formatter rewrites the source text rather than parsing and re-printing it.
Why is my section called "database.mysql" instead of nesting?
Because that is what the header literally says, and the table shows sections as written. Some parsers treat a dot in a header as nesting and some treat it as part of the name — configparser takes the name literally, for instance. INI to JSON is where you choose which reading you want.
Does it handle systemd unit files?
Mostly. A unit file is INI-shaped and reads fine here, but systemd's own syntax has rules of its own — directives that may legitimately repeat, and a trailing backslash that continues a line. Treat the table as a readable view of the file rather than as systemd's interpretation of it.
Is my file uploaded anywhere?
No. Parsing and rendering happen in this tab, which is the whole reason to use a browser tool for a config file — a my.cnf or a provisioning profile carries credentials, and posting one to a server for a five-millisecond parse is a bad trade.