The Java-to-JSON handoff
To convert Java properties to JSON, parse the text with java.util.Properties.load(Reader)-style rules and emit every value as a JSON string.
The Properties to JSON Converter provides that conversion for text you already have as Unicode characters. Paste the properties, convert them locally, and copy the resulting pretty JSON object. The page does not upload a file, contact a Java process, or evaluate placeholders, so it should be treated as a format-conversion step rather than a replacement for application configuration loading.
Java's Properties class and JSON serve different models. Properties is a string key-value format; JSON can represent more types, and its object text does not retain comments or the original separator spelling. The converter therefore produces a final JSON table, not a reversible formatting history. Keep the original .properties file when order, comments, or exact source structure matters.
Convert properties text into JSON
Use the following workflow when you already know the source text and need a JSON representation for another system.
- Decode the source before pasting. Start with the exact source text. If the file was read as bytes, decode it using the charset your application expects and paste the resulting Unicode characters. The converter models load(Reader); it does not reproduce load(InputStream)'s ISO-8859-1 byte decoding.
- Paste the complete character text. Include comments and line continuations. Do not split the text into key-value rows yourself, because an odd run of backslashes can join several visible lines into one logical entry.
- Convert and inspect the result. The converter ignores blank lines and full-line comments, handles supported escapes and continuations, and applies last-value replacement for duplicate keys. Inspect the pretty JSON and the displayed unique-key count.
- Compare keys and escaped values with the source. Check the final unique-key set, duplicate winners, escaped spaces or separators, Unicode escapes, control-character escapes, and values formed by continuation lines.
- Copy the JSON and validate the application contract. Copy the exact output, then verify required keys and expected types against the consuming application's configuration schema. Values remain strings, so parse or cast them only where the schema explicitly requires it. Validate types and required keys against the consuming application's contract rather than relying on the linked JSON Validator.
How Reader-style parsing changes the result
The converter follows the line-oriented format documented for Java's Reader method. Natural lines may end with CRLF, LF, CR, or the end of input. These rules explain why a simple line splitter can produce a different key-value table.
| Source construct | Converter behavior | What to review |
|---|---|---|
| Line endings | Recognizes CRLF, LF, and CR natural-line endings, as well as the end of input. | A visible line break does not always equal a separate logical entry. |
| Blank lines and comments | Ignores blank lines. A line whose first non-whitespace character is # or ! is a comment. | Comments do not appear in the JSON output. |
| Key and value separator | After leading whitespace, the first unescaped equals sign, colon, or properties whitespace ends the key. Following whitespace is skipped, and an optional equals sign or colon after a whitespace separator is also skipped. A line without a separator has an empty value. | Confirm that each intended value belongs to the correct key. |
| Escaped spaces and separators | Escaped separators and spaces remain part of the key or value. | Compare keys containing spaces or literal separator characters carefully. |
| Line continuation | An odd run of backslashes before a line ending continues the logical line. The marker, line ending, and leading spaces, tabs, or form-feed characters on the next natural line disappear. An even run does not continue because the backslashes escape each other. | Reassemble the logical value before checking it against the source. |
| Escapes | Recognizes tab, newline, carriage return, form feed, backslash-compatible escaping, and one lowercase u followed by exactly four hexadecimal digits. A backslash before another character removes the backslash; octal and special backspace behavior are not added. | A malformed Unicode escape returns an error instead of being copied as plausible data. |
| Duplicate keys | Replaces the earlier value with the later value. | The last occurrence determines the final member and value. |
The comment rule applies when # or ! is the first non-whitespace character, so an inline # should not be assumed to begin a comment. Keep the original file when you need to verify comments, ordering, separators, or exact spelling after the conversion.
Keep types and duplicate-key decisions explicit
Java Properties is a string key-value model, so every resulting value remains a JSON string. Spellings such as true, null, 001, 1.5, and 2026-07-20 are not converted to a Boolean, null, number, or date.
If the consuming application expects a Boolean, integer, decimal, or date, perform that conversion later against an authoritative schema. Automatic type guessing can remove leading zeros, change identifiers, or alter application-specific meaning even when the original properties file was valid.
Duplicate properties follow Java's table-replacement behavior: the last value wins. For example, an earlier mode=debug followed by mode=release leaves the final JSON member as "mode": "release". Compare the displayed unique-key count with the final key set you expect after these replacements.
The converter's intermediate record has no inherited prototype. Keys named __proto__, constructor, and toString therefore remain ordinary own data rather than invoking prototype behavior. This protects the conversion step, but the consuming application still needs its normal schema and security checks.
Validate the JSON against the application
A successful syntax conversion does not prove that the result satisfies the target system's configuration contract. The converter has no knowledge of your required keys, application-specific types, or deployment conventions.
| Application question | What the conversion establishes | What you must still verify |
|---|---|---|
| Are all required members present? | The JSON contains the final set of parsed unique keys. | Compare those keys with the application's required-key schema. |
| Are value types correct? | All property values have been serialized as JSON strings. | Apply only the conversions explicitly defined by the application schema. |
| Does the object have the required shape? | The output is a JSON object built from the parsed property table. | Confirm that the consumer wants that structure rather than a different schema. |
| Are defaults or placeholders resolved? | No defaults chain, environment interpolation, variable expansion, Spring profile, or similar framework rule is evaluated. | Resolve those values in the application or deployment system that owns them. |
| Is source history needed? | Comments, original separators, and original ordering are not represented in JSON. | Retain the .properties source when that history matters. |
Use the Java application as the final reference. Compare the browser output with the configuration the application actually loads, confirm that every required key is present, and only then replace an existing configuration file.
Encoding, scope, and size limits
The browser already supplies Unicode characters, so this workflow models load(Reader) on decoded text. It does not emulate the ISO-8859-1 byte decoding performed by load(InputStream). Decode byte-oriented source files with the intended charset before pasting them; otherwise incorrect characters can become part of the JSON.
- Input: Paste character text only. The page does not upload a file, and its conversion runs locally.
- Execution: The converter does not contact a Java process or execute application code.
- Framework features: Defaults chains, XML properties, environment interpolation, Spring profiles, variable expansion, encrypted secrets, and framework-specific configuration rules are outside its scope.
- Size: The limits are 500,000 input characters, 20,000 logical entries, and 2,000,000 output characters.
- Failure behavior: A boundary failure returns no partial JSON, so check the reported limit before assuming the result is complete.
- Secrets: Do not paste production secrets into an untrusted destination or share copied output casually. Local conversion does not remove the secret from the JSON text.
When Java code is the better boundary
If JSON must be generated during application startup, keep the conversion in the application's Java code path. Load characters into java.util.Properties with load(Reader), then pass the intended entries to the JSON serializer already used by the application. Oracle's java.util.Properties documentation describes the Reader-loading contract; the Properties API itself is not a JSON serializer.
- Decode the source bytes with the intended charset and open a Reader.
- Create a Properties instance and call load(reader).
- Select the entries to export, resolving any defaults deliberately rather than mixing them in accidentally.
- Serialize the intended key-value pairs with the application's JSON library, retaining strings unless the schema defines a conversion.
- Validate required keys and exercise the result in the target application.
The browser converter is useful for inspecting known Unicode text or producing a candidate JSON file. It cannot execute this Java path, so an application that loads the file itself remains the final authority.
A dependable handoff checklist
Before replacing live configuration, complete these checks:
- Keep the original .properties file for comments, ordering, and recovery.
- Confirm that the unique-key count matches the expected final table.
- Spot-check escaped values, continuation joins, and duplicate-key winners.
- Validate JSON syntax separately from required-key and type validation.
- Compare the result with the target Java application before deployment.