Properties to JSON Converter

Convert Java .properties files to JSON and back — handles comments, nested keys, and blank lines.

Direction

Output style

.properties input · stays on your device, never in the shared link

or drop a file here

Looks like this contains credentials. They are converted in this tab only — not uploaded, and not included in the link that Share or Copy link produces.

JSON output

{
  "app": {
    "name": "My Application",
    "version": "1.0.0",
    "debug": "false"
  },
  "db": {
    "host": "localhost",
    "port": "5432",
    "name": "mydb",
    "username": "admin",
    "password": "secret"
  },
  "feature": {
    "dark_mode": "true",
    "beta_ui": "false"
  }
}

About .properties file format

Java .properties files store configuration as key=value or key: value pairs, one per line. Lines starting with # or ! are comments and are skipped. Keys with dots (e.g. db.host) can be converted to a nested JSON object ({"db":{"host":"…"}}) or kept as flat keys.

The JSON → .properties direction flattens the object using dot notation, making it easy to round-trip configurations. For other config formats see YAML to JSON, TOML to JSON, and ENV File Parser.

Built and maintained by Meet Shah · Last updated 28 July 2026

What this tool is used for

Reading a Java properties file into a service that consumes JSON.
Diffing a shipped properties file against the one an environment actually loaded.
Feeding a Java service's settings into a Node tool that reads JSON only.
Checking how a parser will treat dotted keys and escapes.
Migrating configuration into a format with real types.

Frequently Asked Questions

What encoding does a .properties file use?: ISO-8859-1, by specification, when read through `Properties.load(InputStream)`. Non-Latin-1 characters must be written as `\uXXXX` escapes — which is why a UTF-8 properties file full of accented characters loads as mojibake and looks like a tooling bug.
How does nesting work?: It does not, structurally. `database.host` is one flat key that happens to contain a dot, and it is Spring and similar frameworks that interpret the dots as a hierarchy. Converting to JSON has to decide whether to nest on dots or keep the flat keys.
Which separators are valid?: `=`, `:` or whitespace, all equivalent, with surrounding whitespace ignored. That flexibility is why a line like `key value` is valid and why a value with a leading space needs the space escaped — otherwise it is treated as separator padding.
How are multi-line values written?: With a trailing backslash to continue onto the next line, where leading whitespace is then stripped. That stripping is deliberate and catches people writing indented multi-line values expecting the indentation to survive.
Are duplicate keys allowed?: The file parses and the last one wins, silently. That is the same hazard as a `.env` file — the configuration reads as if both values are set and exactly one takes effect, which is worth checking before converting rather than after.

Common errors and gotchas

Assuming every dot is nesting, where a key containing a literal dot gains an unintended level.
Expecting types, since every properties value is a string however numeric it looks.
Losing comments, which JSON cannot represent and which often hold the only documentation.
Overlooking backslash escapes and line continuations, which properties files use and JSON does not.
Ignoring the encoding, where older properties files are read as Latin-1 rather than UTF-8.