UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

JSON Properties Converter

Convert JSON and Java-style .properties with escaped dot notation.

About JSON Properties Converter

Java's .properties files are flat dot-separated key lists that Spring Boot, Android, and many Java frameworks use for externalised configuration. Modern tooling prefers nested JSON. Converting between them correctly is trickier than it looks: spring.datasource.url should become a three-level nested object and back, not a flat key. This converter handles that bidirectionally, along with Java-specific details: Unicode escapes for non-ASCII characters, backslash line continuations for multi-line values, and both = and : separators. Unicode escapes are decoded in JSON output so characters are readable, then re-encoded when writing back to .properties for Java runtime consumption. Java developers working with Spring Boot configs, Android developers handling string resources, and i18n teams managing translation files all use this to bridge the two formats.

Why use JSON Properties Converter

Dot Notation ↔ Nested Object

spring.datasource.url becomes {spring: {datasource: {url: ...}}} in JSON and converts back correctly. This preserves the hierarchical intent of Java's dot-notation convention so Spring Boot, Micronaut, and Quarkus read the properties exactly as expected.

Unicode Escape Handling

Java .properties files require \uXXXX escapes for non-ASCII characters. The converter decodes these to readable Unicode in JSON output (中文 instead of \u4E2D\u6587) and re-encodes them correctly when writing back to .properties.

Multi-Line Values

Backslash line continuations where a value spans multiple lines are joined correctly when parsing. On output to .properties, long values can optionally be re-emitted with continuation backslashes to keep lines readable within the file.

Comment Style Aware

Both # and ! comment markers are recognised per the Java spec, stripped when converting to JSON, and a clear warning is shown that they cannot be reconstructed. Copy important comments before converting if they document non-obvious values.

Equals or Colon Separator

Choose = (the Spring Boot and modern convention) or : (the older Java convention) for the key-value separator in .properties output. Both are equally valid per spec; the choice is driven by your project's existing style.

Local-Only Conversion

Database URLs, passwords, API keys, and SMTP credentials stored in production .properties files stay in your browser tab. No data is uploaded, logged, or sent to any server during conversion.

How to use JSON Properties Converter

  1. Choose the conversion direction: .properties to JSON or JSON to .properties
  2. Paste the source content into the input panel
  3. Toggle dot-notation nesting to control whether spring.datasource.url becomes deep JSON or stays as a flat key
  4. Pick the key-value separator for .properties output: equals sign (=) or colon (:)
  5. Decide whether to encode non-ASCII characters as \uXXXX Unicode escapes or keep them as literal UTF-8
  6. Copy the result or download it as a .properties or .json file

When to use JSON Properties Converter

  • Converting a Spring Boot application.properties to JSON for review, documentation, or modification by non-Java tooling
  • Migrating from application.properties to application.yml by converting properties to JSON first and then using the JSON-YAML tool
  • Extracting Android string resources exported as .properties into JSON for localisation pipeline tooling
  • Roundtripping i18n translation files between .properties (for Java runtime) and JSON (for web frontend consumption)
  • Inspecting the resolved property hierarchy of a Spring Boot application by examining the nested JSON structure
  • Converting Maven or Gradle build properties files into JSON for programmatic processing in CI scripts

Examples

Spring application.properties → JSON

Input: spring.datasource.url=jdbc:postgresql://db:5432/app spring.datasource.username=app spring.datasource.password=secret server.port=8080 logging.level.root=INFO

Output: { "spring": { "datasource": { "url": "jdbc:postgresql://db:5432/app", "username": "app", "password": "secret" } }, "server": { "port": 8080 }, "logging": { "level": { "root": "INFO" } } }

i18n strings round-trip

Input: { "login": { "title": "Sign in", "button": "Continue" }, "errors": { "generic": "Something went wrong" } }

Output: login.title=Sign in login.button=Continue errors.generic=Something went wrong

Unicode escape

Input: greeting=\u4F60\u597D farewell=\u518D\u89C1

Output: { "greeting": "你好", "farewell": "再见" }

Tips

  • Spring Boot reads both application.properties and application.yml — convert to JSON first and then use the JSON-YAML tool to produce YAML if your team is migrating formats.
  • Keys with literal dots in them (rare but legal in .properties) need special handling — use a flat-keys mode to keep them un-nested rather than misinterpreting the dot as a level separator.
  • When committing converted .properties files, maintaining the original key order helps reviewers who diff line-by-line rather than structurally.
  • For i18n workflows, .properties is line-based and Git-diff-friendly; JSON integrates better with modern frontend tooling. Pick based on who edits the file most frequently.
  • Production passwords and credentials belong in environment variables or a secrets manager, not committed to version control in either .properties or JSON format.

Frequently Asked Questions

How does dotted key notation translate to nested JSON?
Each dot in a property key acts as a level separator. The key spring.datasource.url produces a three-level JSON structure: {"spring": {"datasource": {"url": "..."}}}. The reverse conversion reconstructs the dotted key from the nested path.
Will accents and Chinese characters survive the conversion?
Yes. Unicode escape sequences like \u4F60\u597D are decoded to their literal characters (你好) in JSON output. When converting back to .properties, the tool re-encodes non-ASCII characters as \uXXXX escapes so the Java runtime reads them correctly.
Are # and ! comments preserved when going to JSON?
No. JSON has no comment syntax, so # and ! comment lines are dropped. A warning is shown before conversion. Keep the original .properties file in version control if comments document configuration decisions.
What separator does the tool use — equals or colon?
Both = and : are valid .properties separators per the Java spec. The tool defaults to = (the Spring Boot convention) but offers : as an alternative. The separator choice does not affect how the JSON is structured.
Can I convert a Spring Boot application.properties file?
Yes. Spring Boot's application.properties uses standard dot-notation keys and the converter maps them to nested JSON matching Spring's relaxed binding convention. The result is the same object shape that Spring Boot would produce if you called Environment.getProperty() with a nested prefix.
How are multi-line values (with trailing \) handled?
Backslash line continuations are joined during parsing. A value split across multiple lines with trailing backslashes becomes a single string in JSON. On conversion back to .properties, the option to re-emit continuations for readability is available.
Will it work for Android strings.xml-derived properties?
For .properties format exports from Android string resources (after conversion from XML), yes. The converter handles the flat key=value format correctly. For strings.xml directly, use the XML-to-JSON tool first.
Are passwords inside the file logged anywhere?
No. All conversion runs locally in your browser. No data is transmitted to any server. Production database passwords, SMTP credentials, and API keys in your .properties files are never exposed.

Explore the category

Glossary

Spring Boot externalised config
Spring Boot's mechanism for loading configuration from application.properties or application.yml files at startup, allowing deployment-time configuration without code changes. Properties use dot-notation keys that map to Java bean properties.
Dot-notation key
A property key that uses dots as level separators to express hierarchy in a flat key-value format. spring.datasource.url represents a three-level path: spring → datasource → url.
Java escape sequence
A backslash-prefixed code representing a special character in Java .properties files. Common examples are \n (newline), \t (tab), and \uXXXX (Unicode code point). These must be encoded correctly for the Java runtime to read the values.
Resource bundle
A set of Java .properties files with locale suffixes (messages_en.properties, messages_fr.properties) used for internationalisation. Each file contains the same keys with locale-specific translated values.
Line continuation (\)
A backslash at the end of a line in a .properties file that tells the parser to treat the next line as a continuation of the current value. Used for long values that would otherwise exceed a comfortable line length.
Unicode escape (\uXXXX)
A four-hex-digit escape sequence for representing non-ASCII characters in Java .properties files. Required in files where the runtime character encoding may not support the literal character. The converter encodes and decodes these automatically.