| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
{{ normalizedYaml }}{{ iniText }}{{ envText }}{{ propertiesText }}| Document | Path | Type | Preview | Copy |
|---|---|---|---|---|
| Doc {{ row.docIndex }} | {{ row.path || '(root)' }} | {{ formatTypeLabel(row.type) }} | {{ row.preview }} |
| Path | Types | Docs | Example |
|---|---|---|---|
| {{ row.path }} | {{ row.types }} | {{ row.docs }} | {{ row.example }} |
INI files remain popular because they are compact, readable, and easy to edit by hand. A few sections and key=value lines are manageable in plain text, but the same file becomes harder to review when you need to compare environments, flatten settings into shell variables, or hand the data to a system that expects JSON or YAML instead.
This converter reads pasted text or a dropped .ini, .cfg, or .txt file and turns it into one consistent configuration view. From that parsed result it produces YAML, JSON, normalized INI text, environment-style variables, properties-style pairs, a path audit, a schema summary, and overview metrics such as key count, scalar count, and maximum depth.
That makes it useful for migration work, troubleshooting, and plain configuration review. You can check what the file actually resolves to before copying it into another format, which is often much safer than assuming every parser will read the original text the same way.
The interpretation is intentionally narrow. Whole-line comments that begin with ; or # are ignored, repeated section headers keep filling the same section, repeated keys inside a section are replaced by the last assignment, and only simple booleans plus base-10 integers or decimals are converted to typed values automatically.
Processing happens in the browser after the tool has loaded, so there is no separate conversion upload step. Even so, configuration files often contain passwords, tokens, internal hostnames, and private paths, so exported text still deserves the same care as the original file.
The parser walks the input line by line after normalizing line endings. A header such as [server] opens or reuses a section object. A line that matches key=value stores one scalar under the current section. If the file has values before any explicit section, those values are collected under a temporary default section and then unwrapped so the final result still reads like a plain object.
Scalar typing stays conservative on purpose. Double-quoted strings decode \n, \r, and \t. Single-quoted strings keep their inner text. Bare true and false become booleans, and only simple decimal-looking numbers become numeric values. Text such as 1e3, yes, or prod ; note stays a string.
After parsing, the tool traverses the resulting object again to build the summary badges, the Overview rows, the flattened Paths list, and the grouped Schema table. That shared traversal is important because every export is derived from the same interpreted data, not from separate ad hoc conversions. If a duplicate key warning or a skipped-line warning appears, that same decision already affects the YAML, JSON, env, properties, and regenerated INI tabs.
Formatting options adjust presentation rather than meaning. You can choose JSON spacing, YAML indentation, YAML line width, sorted YAML keys, forced YAML quotes, quote style, anchor expansion, dot or slash path notation, the visible path preview limit, an environment-variable prefix, and whether generated env keys are uppercased. If the YAML formatter library is unavailable after load, the tool warns instead of inventing YAML output.
INI text
-> section and key parse
-> typed configuration object
-> summary + paths + schema
-> YAML / JSON / INI / Env / Properties| Input pattern | How the tool reads it | Why that matters |
|---|---|---|
[section] |
Starts or reopens a named section object. | Repeated section headers extend the same section instead of creating separate documents. |
key=value |
Stores one scalar under the current section. | The exported formats all reflect that parsed key path. |
; comment or # comment |
Ignored when the trimmed line starts with the comment marker. | Whole-line comments never appear in converted output. |
mode=prod ; note |
Treated as one string value. | Inline comment-like text is preserved because only whole-line comments are stripped. |
| Repeated key in one section | The last assignment replaces the earlier one. | You get a warning so the overwrite is visible before export. |
Line without = |
Skipped and reported as unparseable. | That setting disappears from every downstream view until the line is fixed. |
true, false, 8080, 3.5 |
Converted to boolean or number values. | JSON and YAML emit typed scalars, while env and properties keep plain text representations. |
| View | What it preserves well | What to double-check |
|---|---|---|
YAML |
Nested structure and typed scalars with readable formatting. | Sorting, quoting, wrapping, and anchor settings affect presentation. |
JSON |
Object structure and typed values in a strict interchange format. | Spacing only changes readability, but duplicate INI assignments were already collapsed before JSON was built. |
INI |
A cleaned key-value view grouped by first path segment. | Section names and keys are sanitized to lowercase underscore tokens, so it is a normalized rewrite rather than a byte-for-byte round trip. |
Env and Properties |
Flat scalar leaves that are easy to copy into scripts or mapping sheets. | Flattened names can differ from what a specific dotenv loader or properties parser expects, so inspect a few critical keys first. |
Paths and Schema |
The clearest audit trail for discovered names, types, and sample values. | Preview trimmed affects the visible path table, not the full export set. |
The safest workflow is to trust warnings before you trust pretty output. Paste the INI, let the summary settle, and check whether the key count, scalar count, and warning badges make sense. If those first signals look wrong, copying YAML or env text early only spreads the mistake into a different format.
For most files, Overview is the quickest first stop because it shows top-level keys, sample keys, sample values, and depth in one place. Paths is the next step when you need exact flattened names, and Schema is where you confirm that a setting became a string, number, or boolean in the way you expected.
| Use case | Best tab | Reason |
|---|---|---|
| Clean up a config into a readable structured file | YAML |
It keeps nested structure visible and can sort or quote values for consistency. |
| Feed another structured tool or API | JSON |
It gives you strict object output with explicit booleans and numbers. |
| Review shell-style key names | Env plus Paths |
You can compare the generated variable names against the flattened source paths before export. |
| Prepare a flat handoff list for documentation or spreadsheets | Properties or Paths |
Both are easy to scan line by line, and the CSV exports help with review. |
| Check whether a suspicious value stayed text | Schema and JSON |
The schema type plus the JSON rendering make typing decisions obvious. |
Use dot paths when you want something close to object notation, such as database.pool. Switch to slash paths when you want a filesystem-like view that separates segments more visually. For env output, the prefix box is most helpful when the destination system expects a shared namespace such as APP_ or SERVICE_.
If the path table shows Preview trimmed, treat it as a reminder to review more of the discovered keys, not as proof that data was lost. Raise Max preview paths for on-screen inspection, then copy or download the full paths or schema table once the first slice looks correct.
INI content or drop a local .ini, .cfg, or .txt file onto the editor. Use Load sample if you want to see the expected behavior before working with a real file.No INI data detected. means the current input did not produce any usable assignments. Skipped line N: unable to parse. means a line does not match the expected section or key=value pattern.Overview, Paths, and Schema to confirm structure, names, and types. This is the moment to notice that 1e3 stayed a string, or that an inline semicolon remained part of the value text.Advanced only when you need a specific presentation. That is where JSON spacing, YAML formatting, path style, preview size, env prefix, and uppercase env behavior are controlled.Apply to editor to replace the current input with the generated YAML for a follow-up pass.The main thing to remember is that this tool shows a normalized reading of the INI text. It does not preserve comments, original spacing, or every parser-specific quirk that exists across different runtimes. A clean YAML or JSON result means the file was read cleanly by this parser, not that every other INI reader on every platform would make the same decisions.
That distinction matters most with duplicates, inline comment-like text, and borderline numeric strings. The parser accepts only one winner for a repeated key in the same section, keeps inline ; or # text as part of the value, and does not treat scientific notation as numeric input. Those are deliberate choices, and the warning badges plus schema types are there to make those choices easy to verify.
| Signal | Meaning | What to do next |
|---|---|---|
Duplicate key section.key replaced. |
The later value in that section won. | Check whether the overwrite was intentional before trusting any export. |
Skipped line N: unable to parse. |
A line did not match the supported INI pattern. | Fix the source line and rerun, because that setting is absent from all outputs. |
Preview trimmed |
The visible path list hit the preview limit. | Increase Max preview paths or use CSV export for a fuller audit. |
string in Schema where you expected a number |
The value did not match the tool's narrow numeric rules. | Check for quotes, inline notes, or scientific notation in the source text. |
Flat exports deserve one extra layer of caution. Environment variables are still text values even when they look numeric or boolean, and dotenv conventions vary between ecosystems. Properties-style output is also just a flattened text view here, not a promise of full compatibility with every loader's escaping or continuation rules. Use Paths and Schema as the audit trail before you rely on those flatter outputs in production workflows.
[server]
host=localhost
port=8080
[database]
user=appuser
pool=5
This is the straightforward case. Overview shows one document with four scalar values. Paths lists server.host, server.port, database.user, and database.pool. Schema confirms that server.port and database.pool became numbers, so JSON emits numeric literals and an env prefix such as APP yields keys like APP_SERVER_PORT=8080.
[app]
mode=prod ; keep for now
mode=stage
enabled=true
timeout=1e3
The second mode line overwrites the first one, so the warning badge reports a duplicate replacement and the final value becomes stage. enabled becomes a boolean, but timeout stays a string because the tool accepts only simple decimal notation for numbers. That difference is visible immediately in Schema and in the JSON output.
[server]
host localhost
port=8080
The missing equals sign on the host line triggers Skipped line 2: unable to parse. As a result, the regenerated outputs contain port but not host. This is why the warning state should be reviewed before copying any converted text into another file or system.
Because the parser removes only whole-line comments. A line such as mode=prod ; note is treated as one value assignment, so ; note remains part of the string unless you remove it yourself.
No. The outputs are normalized renderings of the parsed data. Comments, original spacing, and the exact original section order are not preserved as archival content.
Those views are built from flattened paths. Env keys replace separators with underscores and can be uppercased, while regenerated INI section names and keys are sanitized to lowercase underscore tokens so they remain safe as simple INI text.
The converter runs in the browser after the page loads and does not perform a separate per-file upload for conversion. You should still treat pasted or dropped configuration as sensitive local data.
If the YAML formatting library did not load correctly, the tool shows a warning instead of producing partial YAML. Reload the page and try again if that happens.
[server] that groups related settings.server.port or server/port that points to one parsed value.key=value text view built from parsed scalar paths.