The Properties to JSON Converter parses Java load(Reader)-style .properties text and produces a pretty JSON object whose keys match the original property names exactly. It follows the character-based Reader model documented in Java's java.util.Properties class, handling line continuations, escape sequences, comment skipping, and duplicate-key replacement with the same rules the Java runtime applies. Keys are preserved verbatim, so identifiers like dbUrl, maxRetries, or userName appear in the JSON exactly as they appear in the source file, and every value is serialized as a JSON string. This makes the converter a reliable step in workflows that move configuration from Java properties files into JavaScript, Node.js, or other JSON-consuming applications. The conversion runs locally in the browser, with no upload and no server round-trip, and the tool enforces documented limits of 500,000 input characters, 20,000 logical entries, and 2,000,000 output characters, returning no partial JSON when a boundary is exceeded rather than truncating the result.
How the Parser Reads .properties Files
The Properties to JSON Converter models java.util.Properties.load(Reader), the character-based variant of Java's properties loader. Natural lines can end with CRLF, LF, CR, or the end of input, and blank lines are ignored. A line whose first non-whitespace character is # or ! is treated as a comment and discarded before key-value extraction begins.
An odd run of backslashes before a line ending continues the logical line: the continuation marker, the line ending, and any leading whitespace (space, tab, or form feed) on the next natural line all disappear, joining the two physical lines into one logical entry. An even run of backslashes does not continue, because the backslashes escape each other and the line ending is preserved as a character in the value.
After leading whitespace, the key ends at the first unescaped separator: equals sign, colon, or properties whitespace. Whitespace following that boundary is skipped, and an optional equals or colon after a whitespace separator is also skipped. A line with no separator at all becomes a key with an empty value. Escaped separators and escaped spaces remain part of the key or value rather than acting as boundaries, so key\=with\=equals=value stores the key key=with=equals and the value value.
| Rule | Behavior |
|---|---|
| Line endings | CRLF, LF, CR, or end of input |
| Comments | Lines starting with # or ! after leading whitespace |
| Continuation | Odd backslashes before line ending continue the logical line |
| Separators | Unescaped =, :, or whitespace ends the key |
| Empty values | A line with no separator is a key with empty value |
| Escapes | \t \n \r \f \\ \uXXXX only; other \X removes the backslash |
| Duplicate keys | Last value wins (table replacement) |
| Prototype safety | Null-prototype record prevents __proto__ pollution |
Escape Sequences the Converter Recognizes
The converter recognizes the escape sequences documented for Java properties: tab (\t), newline (\n), carriage return (\r), form feed (\f), single backslash (\\), and one lowercase u followed by exactly four hexadecimal digits (\uXXXX). A backslash before any other character simply removes the backslash, matching Java's documented behavior, with no octal sequences, no non-standard shortcuts, and no invented alternatives.
A malformed Unicode escape returns an error instead of being copied as plausible data. If your properties file contains \u00ZZ or \u123 (wrong digit count), the converter stops and reports the problem rather than producing silently corrupted JSON that downstream consumers would struggle to debug. This is the same fail-fast stance the Java reference implementation takes, and it prevents a malformed escape from looking like a valid decoded character in the JSON output.
This matters because property values frequently contain characters that need escaping: URLs with colons, file paths with backslashes, passwords with special characters, or configuration strings with embedded newlines. The converter preserves the intended characters in the JSON string values, so homeDir=C:\\Users\\Admin correctly becomes "homeDir": "C:\\Users\\Admin" in the output, and greeting=Hello\u0020World decodes to "greeting": "Hello World".
From Properties Text to JSON: A Three-Step Workflow
The conversion workflow follows three concrete steps:
- Paste character-based Java properties text into the converter, including comments and continuations if present. The converter accepts whatever line endings your editor produced and skips blank lines without flagging them.
- Convert and compare the unique-key count and escaped values with the source. The converter merges continuation lines and skips comments, so the number of unique keys in the output should match the number of distinct identifiers in your properties file after joining logical lines.
- Copy the JSON, then validate types and required keys against the consuming application's contract. Remember that all values are JSON strings; the converter does not infer booleans, numbers, or nulls. Convert types later against your authoritative configuration schema.
For example, consider this properties fragment:
# Database configurationdbUrl=jdbc:postgresql://localhost:5432/mydbmaxRetries=3userName=admingreeting=Hello\u0020World
After conversion, the JSON output contains exactly four keys, all preserved as written in the source file, with the Unicode escape decoded to a space character in the greeting value. The comment line is discarded, and every value is a JSON string, including maxRetries as "3". If your project uses kebab-case or snake_case identifiers instead, the same preservation rule applies and the output JSON keys match the source property names exactly.
Duplicate Keys and the Null-Prototype Record
When the same key appears more than once in a properties file, the converter keeps the last value, matching Java Properties' table replacement behavior. If your file contains both dbUrl=old-host and dbUrl=new-host, the JSON output will contain dbUrl with the value new-host. This replacement happens during the logical-line build, so duplicates spread across continuation lines are handled the same way as duplicates on separate physical lines: the last logical occurrence wins.
The intermediate record uses a null prototype, so keys like __proto__, constructor, and toString remain ordinary own data properties before JSON serialization. This prevents accidental prototype pollution in downstream JavaScript consumers, a real concern when the JSON output will be parsed by JSON.parse and used as a configuration object in Node.js or browser code. Without a null-prototype intermediate, a maliciously named key in the source properties file could potentially shadow built-in object methods after parsing.
What the Converter Does Not Do
The Properties to JSON Converter is deliberately scoped to the character-based Reader model. It does not emulate load(InputStream)'s ISO-8859-1 byte decoding; the browser supplies Unicode characters directly, so any byte-level decoding must happen before you paste the text. It also does not implement defaults chains, XML properties, environment interpolation, Spring profiles, variable expansion, encrypted secrets, or framework-specific configuration rules.
Automatic type inference is absent by design. Values like true, false, null, 123, 1.5, or 2026-07-20 remain JSON strings in the output. Java Properties is a string key-value model, and guessing scalar types could destroy identifiers, formatting, and application-specific meaning. A property named port with value 8080 should stay a string until your application schema says otherwise, and a property named enabled with value true should stay a string until your schema says it is a boolean.
Comments and the original separator style are not represented in the JSON output. This conversion is not a reversible formatter; it produces a final key-value table, not a properties file with formatting history. Keep the source .properties file if order, comments, or exact separator spelling matters. The converter also does not evaluate placeholders, contact a Java process, or invent behaviors the character-based Reader does not specify.
Validating the Output Against Your Application
After copying the JSON, validate it against your consuming application's contract. Check that all required keys are present, that the types match after your own conversion step, and that the values match the source properties. The converter's output is deterministic: given the same input, it always produces the same JSON, so you can compare results across runs or across team members without worrying about nondeterministic ordering of the keys.
For larger migrations, compare the unique-key count and a sample of escaped values between the converter output and the source file. If the counts match and the sample values decode correctly, the conversion is structurally sound. The Java SE 25 documentation for java.util.Properties provides the authoritative reference for the parsing rules the converter implements, and the related guide on converting .properties files to JSON online covers additional workflow patterns for browser-based configuration conversion.
Never paste production secrets into an untrusted destination or share copied output casually. The converter runs locally, but the clipboard and any downstream system you paste into are outside its control. Treat the converted JSON with the same care you would give the original properties file, and store secrets in a dedicated secret manager rather than in a checked-in properties file in the first place.