Java .properties files convert to a JSON object through three explicit actions: paste the text, verify the unique-key count and escape decoding, then validate the output against the consuming application's schema. The Properties to JSON Converter handles the full line-oriented format that java.util.Properties.load(Reader) documents — character-based text with optional comments, blank lines, escaped separators, continuation lines, and last-key-wins duplicate replacement. Every value in the produced JSON is a string, so identifiers such as 'true', '123', or '001' are not silently rewritten as booleans, numbers, or null. Paste happens in your browser, the conversion runs locally, and the page never uploads the file to a server. After conversion you compare the unique-key count and decoded escapes against your original .properties file, then validate required keys and value types against the application that will read the JSON. This article walks through each step and the limits you should know before pasting production configuration. A tolerance for malformed Unicode escapes is built in: a stray \u without four hex digits returns an error instead of copying plausible-looking text.
What the Converter Reads in Your Properties File
Java's java.util.Properties class loads configuration from a text file using a Reader. According to the Java SE 25 java.util.Properties reference, the load(Reader) method parses line-oriented text in which each natural line may be a key/value pair, a blank line, or a comment. The line ending can be CR, LF, CRLF, or simply the end of input, which makes the format forgiving for files edited across operating systems.
The converter follows that same contract. A line whose first non-whitespace character is # or ! is treated as a comment and discarded. Blank lines are ignored. The key portion runs from the start of the line up to the first unescaped equals sign, colon, or one of the documented whitespace separators. Everything after that boundary is the value, with optional leading whitespace stripped. A line with no separator becomes a key whose value is the empty string.
Three separator forms are accepted, which matches the documented Java behavior: an unescaped equals sign (=), an unescaped colon (:), or a properties whitespace character. The converter also accepts the key/value separation that uses one of these characters after whitespace, then ignores a trailing separator. Because every boundary character can be escaped with a backslash, values like key=with=equals or keys containing spaces remain intact.
How to Convert a Properties File to JSON
The actual conversion takes three concrete actions. The interface is a single paste area on the Properties to JSON Converter page, and the tool does not accept an uploaded file. Follow these steps:
- Paste the entire contents of your .properties file into the converter input, including any comments and continuation lines you want the parser to recognize.
- Convert the text and inspect the unique-key count shown for the result, then read the pretty JSON output to confirm that decoded escape sequences match your source.
- Copy the JSON, then validate required keys and the expected scalar types against the consuming application's schema before replacing configuration.
This workflow exists because the conversion is not reversible: comments are removed, the original separator style is lost, and key ordering follows last-key-wins rather than source order. Treat the source file as the authoritative artifact when any of those properties matter.
Escape Sequences, Continuations, and Duplicates
The escape rules implemented by the converter mirror those documented in the Java SE 25 java.util.Properties specification. Recognized sequences are \t (tab), \n (newline), \r (carriage return), \f (form feed), \\ (single backslash), and one lowercase u followed by exactly four hexadecimal digits. A backslash before any other character is dropped along with the backslash itself, which is how Java keeps a \ before a non-special character harmless.
Continuation lines are joined using the odd-backslash rule. A line that ends with an odd number of backslashes before the line ending is continued: the backslash, the line ending, and any leading whitespace on the next natural line are removed. An even run of backslashes does not continue because the backslashes escape each other in pairs. This behavior matches load(Reader) exactly and is the only safe way to split a long value across lines.
Duplicate keys use the last value, replicating how java.util.Hashtable replaces keys. If the same key is repeated three times with values v1, v2, and v3, the JSON will contain only the third assignment. The internal record is created without an inherited prototype, so keys like __proto__, constructor, and toString remain ordinary own data before JSON serialization — they do not trigger accidental prototype behavior.
A malformed Unicode escape — for instance, \uZZZZ or \u with only three hex digits — returns an error rather than being copied as plausible data. This protects downstream consumers from silently receiving malformed characters.
Why Every JSON Value Stays a String
Java Properties is a string key-value model. The format does not distinguish between the string "true" and a boolean, between "123" and an integer, or between "001" and the same integer without a leading zero. When the converter emits JSON, every value is wrapped in quotes so identifiers and application-specific meanings are preserved.
This matters when your consuming code expects strings like "true" or "001" as configuration values. A naive converter that guessed types could rewrite "001" to the number 1, silently drop the leading zero, and break downstream logic that depends on the original string. Spellings such as true, false, null, 123, 1.5, and date-like values like 2026-07-20 are never auto-converted; they remain ordinary JSON strings.
If the downstream application requires typed JSON — for example, a typed configuration schema — perform that conversion later using a tool that uses an explicit schema. The Properties to JSON Converter's contract is to preserve the string semantics that Java Properties already enforces.
Validating the JSON Against Your Application Contract
After pasting, converting, and copying, the verification you perform before deploying the JSON is the most consequential step. Run the following checks, in this order:
- Count the unique keys in the JSON object and compare it to the number of distinct keys in the source .properties file. The numbers should be equal unless duplicates are intentional.
- Open a few values that contained escape sequences in the source — for example, \n, \t, or \u00E9 — and confirm they decoded to the expected characters in the JSON output.
- Confirm that continuation lines joined into single logical values and that no leading whitespace leaked from the continuation rule.
- Validate the JSON itself with a strict parser to catch any malformed Unicode escape or boundary failure. A boundary failure returns no partial JSON, so an empty result means the input exceeded a documented limit rather than being silently truncated.
- Compare required keys against your application's contract. If the schema needs Boolean values, numbers, or dates, perform a separate, schema-driven conversion after the string-preserving step.
If any of those checks fail, fix the source .properties file and re-convert rather than editing the JSON output. Because comments and ordering are lost during conversion, the source remains the only artifact that can be audited line-by-line. For a deeper walk-through of the escape rules referenced above, see the guide on Properties to JSON: Escape Rules and Duplicate Key Handling.
Limits, Out-of-Scope Features, and Security
The converter operates under three explicit limits: 500,000 input characters, 20,000 logical entries, and 2,000,000 output characters. A boundary failure returns no partial JSON, so you will see an empty result rather than truncated output when the input exceeds any of these thresholds. Before pasting large files, confirm the file is within those limits.
| Limit | Maximum |
|---|---|
| Input characters | 500,000 |
| Logical entries | 20,000 |
| Output characters | 2,000,000 |
The converter also deliberately omits several features documented in Java's Properties class and ecosystem. These are out of scope:
- ISO-8859-1 byte decoding for load(InputStream) — the converter models load(Reader) on browser Unicode text, so any byte decoding must happen before pasting.
- Defaults chains, where a secondary Properties file supplies fallback values for missing keys.
- XML properties files (loadFromXML), which use a different syntax entirely.
- Environment interpolation, Spring profile placeholders, variable expansion, encrypted secrets, or framework-specific rules.
Security is part of the contract. The page does not upload your properties text, does not call a Java process, and does not evaluate placeholders. That said, you should still avoid pasting production secrets into any browser-based tool. Treat pasted content as if it left the tab — keep your secrets in a secrets manager and use a dedicated pipeline for production configuration.
Related reading: How to Use Query String Parser for JSON.