| 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 }} |
Java properties files are simple text configuration documents where each line describes a setting with a key and a value for the runtime environment. They help teams keep ports logging levels feature toggles and many other options in one place so configuration can be reviewed and versioned. Converting that information into richer structured formats makes it easier to reason about complex systems and spot inconsistencies early.
Here the properties text is read as a single configuration snapshot and turned into a structured document that can be explored in several different views. You can move between YAML JSON INI environment variables and regenerated properties text while looking at the same underlying configuration data. A flattened list of paths and a compact schema summary reveal how the configuration is organised and which fields appear together.
A document overview highlights how many keys and scalar values are present and how deeply nested the structure becomes. Sample keys and values provide a quick feeling for the data shape without needing to scan every line by hand. This helps you see whether feature flags credentials placeholders or host entries look complete before you share or commit the file.
Configuration snapshots naturally evolve so it is useful to rerun the same properties after major releases or environment changes and compare the summaries. Remember that the converter can only show what is actually present in the properties file and it does not verify whether any setting is correct for production use.
Java properties configuration is treated as a single logical document composed of individual lines, each of which may be a property, a comment, or an empty line. The engine first normalises line endings, joins continued lines that end with a backslash, and then inspects each completed line to decide how it should be interpreted.
After trimming leading and trailing whitespace, comment lines starting with a hash or exclamation mark are skipped, and every other line is split into a key segment and a value segment. The first occurrence of an equals sign, a colon, or horizontal whitespace is used as the separator, so unescaped spaces in keys are not supported and act as delimiters.
Each raw value is then decoded into a richer JavaScript type. Values wrapped in double quotes can contain escaped newline, carriage return, and tab sequences, and the inner text is unquoted before those escapes are expanded. Unquoted literals that look like booleans or numbers are converted into Boolean or Number values, while everything else becomes a string with simple newline style escapes honoured.
All parsed entries are stored in a single object where each property key appears at most once. When duplicate keys are encountered the most recent value replaces the previous value and a warning is recorded so that the overwrite is visible in the summary area. If no usable properties are found the engine reports a parsing error instead of producing partial output.
The configuration object is then walked recursively to collect statistics across nested objects and arrays. The traversal counts how many keys exist at all depths, how many scalar values are present, and how deeply nested the structure becomes. Sample scalar values are captured from different branches so the overview can show a small but representative list of example values.
A flattening stage turns each reachable value into a row with a document index, a path string, a type label, and a short preview. In dot notation style, object keys are joined with dots while array elements use bracket indices, and keys that contain special characters are quoted so they remain unambiguous. In slash style, path segments are separated by forward slashes and any literal slash characters in keys are escaped, which makes the output easier to use in tools that expect path like segments.
Alongside the raw path list, a lightweight schema map is built that tracks which types appear at each path, in how many documents they occur, and one example value. This schema view is sorted lexicographically by path to make it easier to compare multiple configuration snapshots or search for a particular setting. Preview values are truncated when they are very long in order to keep the tables readable, but all exports still use the full underlying values.
Several derived text representations are generated from the flattened rows. An environment variable view turns each scalar path into a key in upper or lower case, optionally prefixed with a chosen token, while converting dots and slashes into underscores and stripping other non alphanumeric characters. An INI view groups related keys into sections based on the first part of the path and sanitises section names and key names so they are safe within INI syntax. A regenerated properties view writes scalar paths back out as property keys with their current values, and when multiple documents are ever present a document index is prefixed to keep them distinct.
YAML output is produced by passing each document to a dedicated YAML formatting library with user controlled options. Indentation can be set between one and eight spaces, line wrapping is either disabled or constrained to a chosen width, and keys may be sorted alphabetically if you prefer stable ordering across runs. You can also force all scalar values to be quoted and choose single or double quote style, and you can request that anchors are not reused so the output remains fully expanded.
JSON output is produced from either the single document object or an array of documents when that feature is extended. A guarded stringifier tracks previously seen objects so that any accidental circular references are replaced with a neutral placeholder rather than causing a failure. The spacing parameter controls whether the JSON is minified or pretty printed with up to eight spaces of indentation per nested level.
| Input | Accepted Families | Output | Encoding / Precision | Rounding |
|---|---|---|---|---|
| Properties text | Plain text, .properties, .txt | Configuration object | UTF-8 text, inferred types | None |
| Configuration object | Parsed from properties | YAML | Custom indent, optional wrapping | None |
| Configuration object | Parsed from properties | JSON | Pretty or compact, UTF-8 | IEEE 754 Number |
| Configuration object | Flattened rows | INI | Sanitised sections and keys | None |
| Configuration object | Flattened rows | Env text | Upper or lower case keys | None |
| Configuration object | Flattened rows | Regenerated properties | Key equals value lines | None |
| Field | Type | Min | Max | Pattern / Notes |
|---|---|---|---|---|
| JSON spacing | Integer | 0 | 8 | Zero for minified, positive values for pretty printing. |
| YAML indent | Integer | 1 | 8 | Indentation per level in spaces. |
| YAML line width | Integer | 0 | 240 | Zero disables wrapping, positive values set a wrap column or default. |
| Preview paths | Integer | 50 | 2000 | Controls how many flattened paths are shown in the table preview. |
| Path style | Enum | – | – | Either dot notation or slash separated paths. |
| Env prefix | String | – | – | Optional prefix, an underscore is added when needed. |
| Uppercase env | Boolean | 0 | 1 | When enabled, all environment keys are converted to upper case. |
| Force quotes | Boolean | 0 | 1 | When enabled, every YAML scalar is emitted as an explicit string. |
All parsing and conversion is performed in the browser and configuration text is not transmitted to a backend service or stored persistently by this component. Treat any secrets such as passwords or tokens in the properties text with the same care you would in any other configuration file and avoid sharing exported snapshots outside trusted environments.
Properties configuration conversion focuses on turning a plain text properties snapshot into structured formats that are easier to inspect and reuse. Follow these steps to move from raw lines to well organised outputs.
For example, you might start with the following properties snippet:
app.name=Example Service
server.port=8443
logging.level=INFO
feature.alpha=trueAfter parsing, you can export a YAML file for infrastructure as code, an env block for a container definition, and an INI file for a legacy service.
A practical habit is to copy the overview table into documentation alongside each environment so future changes can be reviewed against a known configuration footprint.
No, all parsing and conversion runs entirely in the browser. Configuration text and derived outputs stay in memory only and are discarded when you close or refresh the page.
Avoid pasting secrets on shared machines, even when processing is local.The converter follows deterministic rules for booleans, numbers, quoting, and escape handling, so the same input always gives the same outputs. Accuracy mainly depends on how closely the source file follows conventional Java properties syntax.
Unusual escape sequences or custom formats remain as literal strings.The input is plain text containing properties style lines, either pasted into the editor or dropped from a .properties or .txt file. Other configuration formats such as raw YAML or JSON are not parsed in this tool.
Convert other formats into properties text first if needed.Once the page has fully loaded in your browser, parsing and conversion work without further network access. Reloading the page while offline may fail if supporting resources are not cached locally.
Keep a local copy or ensure the site is reachable when you refresh.After parsing your properties, switch to the env tab, adjust the prefix and uppercasing options, then use the copy or download actions. You can paste the resulting lines directly into shell scripts or deployment manifests.
The env view includes only scalar values, not nested objects or arrays.A skipped line warning appears when a line cannot be split into a key and value using the standard separators. The line is ignored in all outputs, so you may want to fix its syntax or move notes into comment lines.
Checking line numbers against your editor helps you find and correct the issue.Pricing and licensing depend on how this component is hosted within your environment. Refer to the surrounding site, documentation, or your organisation policies for details about permitted use.
The description here covers behaviour only, not legal or commercial terms.Duplicate key warnings indicate that the same property name appears multiple times and only the last value is kept. Review those keys to ensure the final configuration matches your intent and consider cleaning up the file to remove older entries.
Resolving duplicates keeps configuration history clearer for future readers.