Converted output
{{ activeKeyCount.toLocaleString() }} {{ activeKeyCount === 1 ? 'key' : 'keys' }}
{{ summaryLine }}
Requested: {{ requestedSourceFormatLabel }} Resolved: {{ resolvedSourceFormatLabel }} {{ targetFormatLabel }} {{ pathModeLabel }} {{ parserNotes.length }} {{ parserNotes.length === 1 ? 'note' : 'notes' }} {{ duplicateCount }} {{ duplicateCount === 1 ? 'duplicate' : 'duplicates' }}
{{ outputPreview }}
Key-value config converter inputs
Auto detect chooses INI, `.properties`, or `.env` before parsing; choose a pinned format when ambiguous source text must be read one specific way.
{{ sourceModeSummary }}
Paste INI sections, `.properties` keys, or `.env` assignments; parsing follows Auto detect or the pinned source format above.
Drop INI, PROPERTIES, ENV, CFG, CONF, or TXT onto the textarea.
Generate `.properties`, INI, `.env`, JSON, or YAML from the parsed key ledger.
Use Auto for source-native behavior, or force dot, underscore, double underscore, or literal paths.
Keep strings for config parity, or type obvious JSON/YAML scalar values.
Choose which declaration feeds the generated output; all duplicates remain visible in the ledger.
Preserve source comments at the top of text formats or keep them only in parser notes.
Auto quotes values that need protection in `.env`, INI, or `.properties` targets.
Controls how nested paths are joined when `.env` output is selected.
Optional prefix prepended to generated `.env` keys, for example `APP_`.
Controls JSON payload readability and JSON target output.
Sort active keys for stable generated output, or keep source order for review.
{{ sortKeys ? 'On' : 'Off' }}
Use conventional uppercase `.env` keys when the target is `.env`.
{{ uppercaseEnv ? 'On' : 'Off' }}
{{ convertedOutput }}
Path Section Key Value Mode Source Status Copy
{{ row.path }} {{ row.section || 'root' }} {{ row.key }} {{ row.valuePreview }} {{ row.sourceMode }} {{ row.source }} {{ row.status }}
Line Kind Message Detail Copy
{{ note.line || '-' }} {{ note.kind }} {{ note.message }} {{ note.detail || '-' }}
No parser notes for the current source.
{{ jsonPayload }}
Customize
Advanced
:

Introduction:

Small configuration files often look harmless until they move between runtimes. A legacy service may store settings in INI sections, a Java application may read .properties, a container may expect environment variables, and a review ticket may need JSON or YAML. All of those formats can express names and values, but they do not agree on comments, nesting, quoting, duplicates, or type meaning.

A line such as cache.ttl=300 can be read as a flat key, a dotted path, or the seed for an environment variable. A bracketed INI section such as [database] groups later keys, while dotenv syntax treats the whole variable name as the key. Java properties adds escape sequences and continuation lines, so a backslash can change the value that is finally loaded.

Pipeline from source config text through a parsed key ledger to target config text
Common key-value configuration format differences
Format family Typical shape Common migration risk
INI Optional sections such as [database] with key-value rows below them. A destination may not treat sections as nested objects.
.properties Line-oriented keys, separators, escapes, and continuation lines. Escaped characters and line continuations can change the loaded value.
.env Portable variable names assigned with =, sometimes prefixed by export. Names that work as config keys may be invalid or awkward as environment variables.
JSON and YAML Nested mappings with strings, numbers, booleans, and null values. Text values such as true or 5432 may become typed values when that is not intended.

Conversion is safest when the parsed key ledger is treated as the review point. The final text can look tidy while a duplicate key silently chose the wrong declaration, a comment disappeared, or a path split changed hierarchy. The ledger view exposes the original key, generated path, source line, value preview, and active or ignored duplicate status before the text is used elsewhere.

A converter can translate supported syntax, but it cannot know every rule inside the application that will read the result. Deployment frameworks may add interpolation, secret injection, case rules, reserved prefixes, or schema validation after the file is loaded. Validate the generated config in the destination environment before relying on it for production settings.

How to Use This Tool:

Start by making the source format explicit, then review the parsed ledger before trusting the generated config text.

  1. Paste text into Source config, browse for a local text file, drag a file onto the input, or load the sample to see the flow.
  2. Set Source format to Auto detect, INI, .properties, or .env. Pin the format when a short key=value snippet could be read more than one way.
  3. Choose Target format from .properties, INI, .env, JSON, or YAML.
  4. Use Nested key path to control how sections, dots, underscores, double underscores, or literal keys become generated paths.
  5. Choose Value mode. Literal keeps values as text; smart mode converts obvious booleans, null, and safe numbers for JSON or YAML output.
  6. Open Advanced for duplicate policy, comment handling, quoting, ENV separator, ENV prefix, JSON spacing, sort order, and uppercase ENV names.
  7. Check Converted Config, then inspect Key Ledger and Parser Notes. Skipped lines, invalid ENV names, duplicate decisions, or unexpected typed values should be fixed before copying or downloading output.

Use the chart as a quick scan for large files: overloaded sections or duplicate-heavy groups are often easier to spot there before reading every row.

Interpreting Results:

The summary identifies the requested source format, detected source format, target format, captured comments, and parser notes. Those signals help catch parsing mistakes, but the destination application still decides whether the final config is valid.

Converted Config is the text output. Key Ledger is the audit view for path, section, original key, value preview, source line, and active or ignored status. Parser Notes records source-mode evidence, skipped rows, invalid ENV names, duplicate winners, and comments when comments are retained for review.

  • A wrong hierarchy usually means Nested key path should change before the output is reused.
  • An unexpected duplicate winner means Duplicate keys should match the loader behavior being replaced.
  • A value that changed from "5432" to 5432 means smart value mode is active.
  • An unusual ENV variable name often points to the separator, prefix, uppercase switch, or a source key that is not portable as an environment variable.
  • A dense Key Distribution chart can reveal overloaded sections and duplicate-heavy groups before a migration grows harder to review.

Technical Details:

Key-value config conversion starts with line parsing, not simple search-and-replace. INI syntax recognizes bracketed sections and common separators. Properties syntax uses natural lines, optional separators, escape sequences, and backslash continuations. Dotenv syntax focuses on assignment lines, quote handling, comments, and variable-name portability.

The technical center of the conversion is a normalized key ledger. Each parsed row becomes a path, section, raw key, value, source line, separator, and active flag. Rendering then uses only the active rows, applying duplicate policy, path splitting, sorting, quoting, comment policy, value typing, and target-specific naming rules.

Transformation Core:

Key-value config transformation stages
Step Mechanism What to Verify
Detect or choose source Auto detection checks for INI sections first, dotenv-style assignments second, and properties-style lines otherwise. Pin the source family when a short snippet could be valid in several formats.
Parse source lines Comments, blank lines, separators, quoted values, continuation lines, and escapes are interpreted according to the selected family. Parser notes should not skip lines that carry real settings.
Build paths Sections and keys become path segments using source-native, dot, underscore, double-underscore, or literal rules. Ledger paths should match the hierarchy the destination expects.
Resolve duplicates First-wins or last-wins policy chooses the active row for repeated paths and marks the others ignored. The selected policy should match the loader behavior being replaced.
Render target Active rows are emitted as properties, INI, ENV, JSON, or YAML with selected quoting, typing, comments, spacing, and sort options. The generated text should be checked with the destination parser or application.

Source Syntax Map:

Supported source syntax map for key-value config conversion
Source style Accepted shape Important limit
INI Bracketed sections such as [database], followed by rows separated by = or :. Rows without a separator are skipped and reported.
.properties Keys with optional values, Java-style escapes, whitespace separators, and backslash continuations. Values begin as text unless smart JSON or YAML typing is selected.
.env Assignment lines with optional export or declare -x prefixes and quoted or unquoted values. Portable names should start with a letter or underscore and then use only letters, digits, and underscores.
Comments INI accepts # and ; comment lines, properties accepts # and !, and env accepts #. Comments can be preserved in compatible text output, kept in notes, or dropped.

Target Rendering Rules:

Target rendering rules for generated key-value config
Target Path behavior Value behavior
.properties Path segments join with dots, and key characters that need protection are escaped. Text values are escaped for properties syntax, with optional forced quotes.
INI Single-segment rows stay at root; deeper paths become sections with leaf keys. Auto quoting protects empty values, whitespace, and comment-like characters.
.env Path segments join with the selected separator, optional prefix is added, generated names can be uppercased, and unsafe characters are normalized. Text values are quoted according to the selected quote rule.
JSON Path segments build nested objects. Literal mode keeps strings; smart mode can emit booleans, nulls, and finite numbers.
YAML Path segments build nested mappings. Strings that could be misread as YAML syntax or typed scalars are quoted.

Worked Mechanism Path:

Example mechanism path for converting an INI key to JSON
Step Example state Meaning
INI source [database] followed by port=5432 The section and key become the path database.port unless literal mode is selected.
Duplicate policy Two database.port rows The first-wins or last-wins setting chooses the active value and leaves the ignored row visible.
JSON target, literal {"database":{"port":"5432"}} The port remains text for config parity.
JSON target, smart {"database":{"port":5432}} The numeric-looking value becomes a JSON number.

Privacy Notes:

Pasted text and selected files are parsed in the browser for the current session, with no upload required for conversion. Config files often contain credentials, tokens, hostnames, internal paths, and deployment secrets, so treat copied output, downloads, tables, and JSON reports with the same care as the original source.

Worked Examples:

INI to properties

A section named [database] with host=localhost becomes a ledger path such as database.host. Properties output emits that path as a dotted key.

Properties to JSON

A property such as feature.enabled=true becomes "true" in literal mode. Smart mode is appropriate only when the receiving JSON should contain a boolean instead of a string.

Duplicate review

If cache.ttl=300 appears twice, parser notes record which declaration wins and the ledger marks the ignored row. Change the duplicate policy when the original loader uses the opposite rule.

ENV name repair

A source key such as 2BAD=value is flagged as a non-portable ENV name. Rename the key or use target formatting controls so the generated variable can be accepted by the destination shell or platform.

FAQ:

Why did Auto detect choose the wrong source format?

Short key-value snippets can be valid in more than one family. Pin the source format when INI sections, dotenv variable-name rules, or properties escaping should control the parse.

What happens to comments?

Comment lines are captured during parsing. The Comments option decides whether compatible text output includes them, parser notes keep them for review, or conversion drops them.

Can conversion prove that my app will accept the result?

No. The conversion checks supported parsing and rendering rules. The receiving application may still require different names, interpolation behavior, accepted types, schema rules, or secret-handling practices.

Why did a number lose its quotes in JSON or YAML?

Smart value mode is active, so safe numeric-looking strings can become numbers. Use literal mode for ports, IDs, account numbers, and feature values that must remain text.

Does conversion send configuration to a server?

No upload is needed for the conversion workflow. The text is handled in the browser, but the generated output can still contain sensitive configuration values.

Glossary:

Key ledger
The parsed audit table of paths, sections, keys, values, source lines, and active or ignored status.
Path segment
One part of a nested config path, such as database or host.
Duplicate policy
The rule that chooses which repeated key feeds the generated output.
Literal value mode
A mode that keeps parsed values as strings.
Smart value mode
A mode that converts obvious booleans, nulls, and safe finite numbers for JSON or YAML output.
Portable ENV name
An environment variable name that starts with a letter or underscore and then uses letters, digits, or underscores.

References: