Convert nested JSON to .properties

How nested keys become flat keys

Objects are joined with dot-style path segments. Arrays are written with indexes such as [0] or servers[1].host. Empty objects and empty arrays can be represented as {} and [] at their path.

That makes the file easy to scan, but it changes the data model. A consumer reading .properties sees strings by key, not JSON objects, arrays, booleans, or nulls with original types.

Copyable .properties example

{
  "app": {
    "name": "Catalog API",
    "features": ["search", "export"],
    "emptyObject": {},
    "emptyArray": []
  },
  "server": {"port": 8080, "enabled": true},
  "message": "line1\nline2"
}

app.name=Catalog API
app.features[0]=search
app.features[1]=export
app.emptyObject={}
app.emptyArray=[]
server.port=8080
server.enabled=true
message=line1\nline2

Export a properties file

1. Open the JSON configuration in JSON All-in-One.
2. Choose or query the object or array that should become properties.
3. Choose Export, then .properties.
4. Save the file and load it with the receiver you actually use.
5. Check dotted keys, indexed arrays, Unicode, newlines, equals signs, and empty containers before merging the file into a project.

Check what the receiver sees

A Java Properties reader returns strings. In the example above, server.port is read as the string 8080, not an integer. server.enabled is the string true, not a boolean. Your framework may convert those strings later, but that is framework behavior, not a property of the file format.

Spring Boot, Java resource bundles, Gradle properties, and custom config loaders can disagree about encoding, escaping, profile naming, and binding. Treat the export as a starting file and verify it in the receiving system.

The safest smoke test is small: load the generated file, print the sorted keys, and compare five expected values. Include one nested value, one array index, one escaped newline, one empty container, and one key with punctuation if your source uses punctuation.

Dots and arrays can collide with conventions

Dotted paths are convenient, but they can be ambiguous when the original JSON key itself contains a dot. Arrays also become indexed keys, which may or may not match the application convention. If database.hosts[0] is not the name the receiver expects, reshape the JSON first.

The safest workflow is to export a small fixture, load it through the target reader, and compare the resulting keys and values with an expected list.

Showing the exact key convention and testing it in the target reader is more reliable than assuming any export path is collision-free for every configuration system.

• Generate Java models from JSON
• Use YAML for readable nested configuration
• Use TOML for table-based configuration