⌘ K
properties → json · dot paths · nested · comments · live

Parse .properties as JSON

Convert Java / Spring .properties files into a nested JSON object. Dotted keys re-expand into tree structure; comments and blank lines are ignored.

Properties → JSON
Input
209 B
7 lines
Output
300 B
20 lines
Status
ready
live
Ratio
1.44×
out/in
input · .properties
output · json
{
  "server": {
    "host": "localhost",
    "port": "8080"
  },
  "spring": {
    "application": {
      "name": "my-service"
    },
    "datasource": {
      "url": "jdbc:postgresql://localhost/db",
      "username": "admin"
    }
  },
  "logging": {
    "level": {
      "root": "INFO"
    }
  }
}
Quick Start

How parsing works

Each line is split on the first equals or colon. Comments (# and !) and blank lines are skipped. The key is split on dots and each segment becomes a level of the nested JSON output.

  1. 01

    Paste .properties

    Spring Boot, JBoss, Tomcat — anything that speaks java.util.Properties.

    Parsing is strict-but-tolerant — comments and trailing commas are accepted on input where the source format historically permits them; output stays canonical.

    inputstricttolerantliveparse
    in · source.props · live
    server.port=8080
    loaded · parsedtarget · ready
  2. 02

    Comments dropped

    Lines starting with # or ! are ignored, blank lines too.

    Conversion preserves type information where the target supports it (numbers stay numeric, booleans stay boolean) so the destination parser never has to re-coerce.

    cleantype-preservinglosslesslivememoised
    #/! · optionsskip · live
    # config (ignored)
    options applied · liveround-trip
  3. 03

    Dot-path expansion

    server.port=8080 becomes { server: { port: "8080" } }.

    Re-encoding is idempotent: running output back through the same converter produces the same bytes, which keeps round-trips git-friendly.

    nestidempotentround-tripdiff-cleandeterministic
    dotted · convertedtree · ready
    { server: { port: "8080" } }
    converted · livediff-clean
  4. 04

    Copy or download

    Drop the JSON into config loaders, secret managers or test fixtures.

    Copy writes via navigator.clipboard.writeText; downloads use the target’s native MIME so editors apply the right syntax highlighting on open.

    exportclipboardtarget MIMEblobclient-side
    ✓ · copiedready · done
    ✓ Copied
    shipped · ready to shipsuccess
Pro tips

Converting between formats, safely

Pick the strictest source format

Lossy formats hide bugs. Choose JSON or YAML as your source-of-truth, convert downstream as needed.

Round-trip in CI

If your converter is idempotent, your CI can verify A → B → A equals the original. Catches subtle data loss.

Numbers vs strings differ

YAML/TOML have a number type; CSV doesn’t. Quote IDs in CSV to keep leading-zero values intact.

Watch character encoding

Source format may be Latin-1 / Windows-1252; target should be UTF-8. Convert encoding before structure.

Preserve comments where you can

YAML and TOML support comments. Don’t silently drop them — they often encode intent.

Schema-aware beats blind

Use a schema to guide conversion. Field types, required-ness, and defaults survive better with structure.

Related toolsJSON to PropertiesINI to JSONENV to JSONTOML to JSONYAML to JSONXML to JSON
Use Cases

When to convert Properties to JSON

Audits, migrations, modernisation.

Spring → Node migration

Move Spring Boot config into a Node service's JSON loader. Type information survives: numbers stay numeric, booleans stay boolean, strings stay strings. The destination parser doesn't have to re-coerce, which avoids the "'true' becomes "true"" bug class.

round-trip safe

Secret manager imports

Bulk-load a .properties bundle into Vault or AWS SSM. Run output back through the inverse converter to verify idempotent round-trips in CI. A → B → A should produce byte-identical input — if it doesn't, you've found data loss.

type-preserving

Audit reviews

Read a flat properties file as a structured tree. Comments and metadata survive where the target format supports them (YAML, TOML, HCL). The tool doesn't silently drop intent-encoded annotations, which keeps your config self-documenting.

schema-aware

Diffing

JSON form makes it easier to diff config across environments. Pair with a schema (JSON Schema, OpenAPI, Zod, Pydantic) to catch shape drift on either side. Catch breaking changes at conversion time rather than at runtime in production.

lossless

Localisation bundles

Convert i18n .properties bundles into JSON dictionaries. Output respects target-format conventions: quoting in CSV, indent in YAML, brackets in JSON. Existing parsers don't need patches, and the result drops into legacy pipelines unchanged.

i18n

Documentation

Render Spring config as JSON in onboarding docs. Encoding-aware: handles UTF-8 vs UTF-16 vs Latin-1 / Windows-1252 transparently. The character-set surprise that breaks "works on my machine" doesn't apply here.

spec-grade
FAQ

Frequently asked questions

No — every value is preserved as a string. java.util.Properties is string-only by spec.
Yes — either works, with optional surrounding whitespace, matching the Properties spec.
Continuations with a trailing backslash aren't handled yet — pre-process them first.
If you have both server=foo and server.port=8080, the later setDeep call wins; clean up your inputs first.
No. Parsing runs locally in your browser.
Suggest a tool

Something missing?

Tell us what you need. We ship the top requests every two weeks.

Sent straight to the maintainers · no account needed
47 in queue·8 shipped this month
Request queued. Thanks!