Convert Properties to JSON

Convert Java properties file format to JSON with support for nested objects, arrays, and custom separators.

Input (Properties File)
Options
Properties File Format
Output JSON Format
Output (JSON)

Related Tools

Convert JSON to Properties

Convert JSON objects to .properties format with dot notation.

Json

Flatten JSON Object

Convert nested JSON objects into a single-level structure with dot-notation keys.

Json

Extract JSON Values

Extract all values from JSON objects at specific depths with options for complex value handling.

Json

Extract Text from JSON

Extract string content from JSON with optional depth and type filters.

Json

What It Does

Convert Java .properties files to JSON format instantly with this free online tool. The .properties format is a widely used configuration standard in Java applications, Spring Boot projects, and many JVM-based frameworks — but its flat, line-based structure can be limiting when you need to work with modern APIs, JavaScript applications, or tools that expect structured JSON data. This converter intelligently parses your properties content, including dot-notation keys like `server.port=8080`, and transforms them into properly nested JSON objects. Type inference automatically detects numbers, booleans, and strings so your output JSON reflects the correct data types rather than wrapping everything in quotes. Whether you're migrating a legacy Spring application to a Node.js backend, feeding configuration data into a CI/CD pipeline, or simply need to inspect your config in a more readable hierarchical format, this tool handles the heavy lifting in seconds. No installation, no dependencies, no sign-up required — just paste your properties content and get clean, valid JSON output ready to copy, use, or integrate into your workflow.

How It Works

The Convert Properties to JSON applies its selected transformation logic to your input and produces output based on the options you choose.

It applies a fixed set of transformation rules to your input, so the output is stable and easy to verify.

All processing happens in your browser, so your input stays on your device during the transformation.

Common Use Cases

  • Migrating a Spring Boot or Java EE application's configuration files to a Node.js or Python service that consumes JSON config.
  • Converting application.properties or application.yml-adjacent files into JSON for use with configuration management tools like Consul or etcd.
  • Transforming flat .properties-based i18n locale files into nested JSON objects compatible with JavaScript internationalization libraries like i18next.
  • Quickly inspecting and debugging complex Java configuration files by viewing them as a hierarchical JSON tree instead of a flat list of key-value pairs.
  • Generating JSON fixtures or test data from existing properties files when writing integration tests for multi-language systems.
  • Feeding configuration values from a .properties file into a REST API or JSON-based pipeline without manual reformatting.
  • Onboarding new developers who are unfamiliar with the .properties format by converting it to the more universally understood JSON structure for documentation purposes.

How to Use

  1. Paste your entire .properties file content into the input area on the left — this can include comments (lines starting with # or !), blank lines, and keys using dot notation like `database.host=localhost`.
  2. The tool immediately parses your input and renders the equivalent JSON structure in the output panel on the right, grouping dot-notated keys into nested objects automatically.
  3. Review the output JSON to confirm that nested objects, arrays, and data types (numbers, booleans, strings) have been correctly inferred from your property values.
  4. Use the Copy button to copy the formatted JSON to your clipboard, or download it directly as a .json file for use in your project.
  5. If you see unexpected output, double-check your .properties file for duplicate keys or non-standard syntax, then re-paste the corrected content for an updated result.

Features

  • Dot notation parsing that converts keys like `app.server.port=8080` into fully nested JSON objects: `{ "app": { "server": { "port": 8080 } } }`.
  • Automatic type inference that detects integers, floats, booleans (`true`/`false`), and null values so the output JSON uses the correct types rather than plain strings.
  • Comment stripping that cleanly removes lines beginning with `#` or `!` from the output without disrupting surrounding key-value pairs.
  • Support for multi-line values using the backslash line-continuation character common in Java .properties files.
  • Handles both `=` and `:` as key-value delimiters, covering the full range of valid .properties syntax as defined by the Java specification.
  • Instant, client-side conversion with no server upload required — your configuration data never leaves your browser, keeping sensitive credentials and settings private.
  • Formatted JSON output with proper indentation for maximum readability, ready to drop directly into a codebase or configuration system.

Examples

Below is a representative input and output so you can see the transformation clearly.

Input
name=Ada
score=9
Output
{
  "name": "Ada",
  "score": "9"
}

Edge Cases

  • Very large inputs may take a few seconds to process in the browser. If performance slows, split the input into smaller batches.
  • Mixed formatting (tabs, line breaks, or inconsistent delimiters) can affect output. Normalize spacing first if needed.
  • Convert Properties to JSON follows the selected options strictly. If the output looks unexpected, re-check option settings and input format.

Troubleshooting

  • Output looks unchanged: confirm the input contains the pattern this tool modifies and that the correct options are selected.
  • Output differs from a previous run: confirm that the input and every option match, because deterministic tools should repeat when the settings are identical.
  • Unexpected characters: check for hidden whitespace or encoding issues in the input and try normalizing first.
  • Slow processing: reduce input size or try a modern browser with more available memory.

Tips

When converting properties files that contain sensitive data like database passwords or API keys, this tool processes everything locally in your browser — nothing is sent to a server, so your secrets stay private. For large configuration files with deeply nested dot keys, scan the JSON output tree to verify the hierarchy matches your intent, especially if any keys share a prefix segment (e.g., `server.name` and `server.name.full` can cause structural conflicts). If your .properties file uses Unicode escape sequences (e.g., `\u0041`), make sure they are properly decoded before converting, as some editors may store them literally. Always validate your output JSON with a JSON linter before dropping it into a production configuration to catch any edge cases introduced during conversion.

The Java .properties file format has been a cornerstone of application configuration since the earliest days of the Java platform. Defined as part of the `java.util.Properties` class, the format is deliberately simple: each line contains a key-value pair separated by an equals sign (`=`) or colon (`:`), comments begin with `#` or `!`, and blank lines are ignored. This simplicity made it a natural choice for externalizing configuration from compiled code in an era when readability and ease of editing were paramount. However, the flat nature of the .properties format becomes a limitation as applications grow in complexity. Modern configuration needs — microservice environments, multi-environment deployments, feature flags, and deeply structured settings — map far more naturally to hierarchical data structures. This is precisely why JSON has emerged as the dominant format for configuration in the JavaScript ecosystem, REST APIs, and cloud-native tooling. Converting from .properties to JSON is not just a cosmetic change; it's often a necessary step in modernizing an application's configuration strategy. **How Dot Notation Creates Structure** Java developers long ago adopted a convention of using dot-separated key names to imply hierarchy — for example, `spring.datasource.url`, `spring.datasource.username`. While the .properties format itself treats these as flat string keys, the dots carry semantic meaning understood by frameworks like Spring, Micronaut, and Quarkus. When converting to JSON, a smart parser honors this convention and produces genuinely nested objects, making the configuration hierarchy explicit and machine-readable by any JSON consumer. For example, the following properties block: ``` server.host=api.example.com server.port=443 server.ssl.enabled=true ``` becomes the far more expressive JSON: ```json { "server": { "host": "api.example.com", "port": 443, "ssl": { "enabled": true } } } ``` **Properties vs. YAML vs. JSON for Configuration** It's worth understanding where .properties sits relative to its common alternatives. YAML, also popular in the Java world (especially as `application.yml` in Spring Boot), supports native hierarchy and is more human-readable for complex structures, but it's whitespace-sensitive and notoriously prone to subtle indentation errors. JSON is strict, widely supported across all languages and platforms, and trivially parseable — but more verbose and less friendly to hand-editing. The .properties format wins on simplicity and editability but loses on structure and portability. For teams moving toward polyglot architectures or integrating Java services with JavaScript, Python, or Go components, converting configuration to JSON creates a common language all services can consume without format-specific parsing libraries. **Real-World Migration Scenarios** The most common reason developers reach for a properties-to-JSON converter is a technology migration. When a Java backend is being replaced or supplemented by a Node.js API gateway, all existing configuration stored in .properties files needs to be ported. Rather than manually re-typing hundreds of key-value pairs into JSON objects — a slow, error-prone process — automated conversion preserves the full configuration set accurately. Similarly, DevOps engineers building Kubernetes ConfigMaps or Helm charts often need to translate .properties-based app configs into JSON or YAML manifests, and bulk conversion tools accelerate that process dramatically. Internationalization (i18n) is another frequent use case. Many legacy Java applications store translation strings in .properties files using dot-namespaced keys. Modern frontend frameworks like React and Vue rely on JSON-based i18n libraries, so converting those translation files is a prerequisite for sharing string resources between the backend and frontend layers of a full-stack application.

Frequently Asked Questions

What is a .properties file and when is it used?

A .properties file is a plain-text configuration format used primarily in Java applications to store key-value pairs outside of compiled code. It's defined by the `java.util.Properties` class in the Java standard library. Common uses include externalizing database URLs, server ports, feature flags, and internationalization strings in frameworks like Spring Boot, Hibernate, and Apache Ant. Each line follows the format `key=value` or `key: value`, with `#` and `!` used for comments.

How does dot notation in .properties files get converted to nested JSON?

Dot notation in .properties keys — such as `app.server.host=localhost` — implies a hierarchical relationship between configuration values. When converting to JSON, each dot-separated segment becomes a level in a nested object. So `app.server.host=localhost` and `app.server.port=8080` together become `{ "app": { "server": { "host": "localhost", "port": 8080 } } }`. This conversion makes the implied structure explicit and consumable by any JSON parser, regardless of programming language.

Will the converter handle type inference, or will all values become strings?

This tool performs automatic type inference on property values. Numeric values like `8080` or `3.14` are output as JSON numbers, boolean-like values (`true`, `false`) become JSON booleans, and everything else is treated as a string. This means your output JSON is semantically correct and ready to use without additional post-processing to cast types. Always review the inferred types for critical values like ports, timeouts, or flags to confirm they match your expectations.

Is it safe to paste sensitive configuration data like passwords or API keys?

Yes. This tool runs entirely client-side in your browser using JavaScript. Your .properties content is never transmitted to any external server — all parsing and conversion happens locally on your machine. That said, it's still good practice to avoid pasting production credentials into any web-based tool when a local alternative exists. For highly sensitive environments, consider running an equivalent command-line conversion script locally.

What happens if I have duplicate keys in my .properties file?

In the Java .properties specification, duplicate keys are technically allowed, with the last occurrence taking precedence. Most converters, including this one, follow the same convention and use the last defined value for any repeated key. If your file contains duplicate keys, review the JSON output carefully to confirm the retained value is the correct one. Duplicate keys in .properties files are often the result of configuration drift and can silently mask intended settings.

What's the difference between converting .properties to JSON vs. converting .properties to YAML?

Both JSON and YAML can represent the same nested configuration hierarchy derived from dot-notated .properties keys, but they serve different audiences. JSON is stricter, universally supported across all programming languages, and ideal for APIs, JavaScript applications, and machine-to-machine communication. YAML is more human-readable, supports comments (which JSON does not), and is popular for Kubernetes manifests, Docker Compose files, and Spring Boot's `application.yml`. If your target system is a JavaScript app or REST service, JSON is the better choice; if you're writing infrastructure-as-code or staying within the Spring ecosystem, YAML is often preferred.