The Properties to JSON Converter parses Java .properties text — the same line-oriented format read by java.util.Properties.load(Reader) — and emits a pretty-printed JSON object directly in your browser, with no file upload and no Java process involved. All keys and values come out as JSON strings, so the converter never guesses types, never invents octal or backspace escapes, and never copies malformed Unicode through as plausible data. Lines may end with CRLF, LF, CR, or the end of input and are treated identically, blank lines are dropped, and any line whose first non-whitespace character is # or ! is treated as a comment and removed before output. Backslash continuations, escaped separators, escaped spaces, and the single-lowercase-u followed by exactly four hexadecimal digits escape are all decoded exactly as the Java specification describes. Duplicate keys use the last value, matching how java.util.Hashtable replacement works in code, and the intermediate record is built on a null prototype so keys named __proto__, constructor, or toString stay ordinary data instead of inheriting prototype behavior during JSON serialization.
What the Converter Reads and Writes
The converter takes the character-based .properties format as input — not raw bytes — because browsers already expose Unicode text. That means you paste the contents of a config.properties resource bundle, a Spring application.properties excerpt, or a similar key-value file used in cross-platform or polyglot projects, and the tool produces one top-level JSON object. Comments, blank lines, and separator style are not preserved in the output: JSON has no syntax for them, so the conversion is intentionally not a reversible formatter. Keep the original source if comment placement, ordering, or the equals-versus-colon separator style matters downstream.
| Input element | How the converter treats it |
|---|---|
| Lines ending in CRLF, LF, or CR | Normalized during parsing; line endings do not appear in the output |
| Blank lines | Ignored |
| Lines starting with # or ! | Treated as comments and removed |
| Separator characters =, :, or whitespace | First unescaped separator ends the key; escaped separators stay in the key |
| Trailing \ before a line ending | Logical line continues onto the next natural line |
| Duplicate keys | Last value wins, matching Java's Hashtable replacement |
| Escape sequences \t \n \r \f \\ | Decoded to their control characters in the output |
| Escape sequence \uXXXX (lowercase u, exactly 4 hex digits) | Decoded to the matching Unicode code point |
| Malformed Unicode escape | Returns an error instead of copying plausible-looking data |
That mapping is documented in the Java SE specification for java.util.Properties, and the converter implements it character-by-character rather than by splitting on newlines naively. As a result, a key like host\:port = db.local — where the colon is escaped — is read as the literal key host:port rather than being split at the colon.
How the Parser Handles Continuation Lines and Escapes
One of the easiest places for a naive conversion to go wrong is the backslash continuation rule. A natural line that ends with an odd number of backslashes continues onto the next physical line; an even run does not, because the backslashes escape each other in pairs. The converter drops the continuation marker, the line-ending characters, and any leading space, tab, or form-feed characters on the next natural line, so a key split across two source lines still parses as one logical entry. This matters when a value carries embedded newlines, which Java expresses as a trailing backslash followed by a line break and indentation on the continuation line.
Escape decoding is deliberately narrow. The converter recognizes tab, newline, carriage return, form feed, a backslash-compatibility escape, and one lowercase u followed by exactly four hexadecimal digits. A backslash in front of any other character simply removes the backslash, as the Java documentation specifies; the tool does not invent octal escapes (\077) or a special \b backspace interpretation that Properties never defined. A value containing \b therefore comes out as the single character b, which is the documented behavior. This is also why a malformed \u sequence — for instance \u12Z9 or \u123 with only three hex digits — surfaces as an error rather than getting silently passed through, which prevents configuration typos from becoming valid-looking JSON.
How to Convert Properties Text to JSON
The Properties to JSON Converter walks you through three explicit stages, and each stage is something you can verify by eye before moving on.
- Paste the character-based Java properties text into the converter, including any comments, blank lines, backslash continuations, or escaped separators that the original file uses. The page reads the text locally in the browser, so the input never leaves your machine.
- Convert and compare the unique-key count and the escaped values with the source. If the source had 42 entries before duplicates and the converter reports 38 unique keys, four duplicates were collapsed using last-value-wins, which matches how java.util.Hashtable handles repeated keys. Spot-check a value you know was escaped — for example a tab character or a \u00e9 sequence — to confirm decoding.
- Copy the JSON, then validate types and required keys against the consuming application's contract. Because every value comes out as a JSON string, you will likely need to coerce numbers, booleans, and dates in code or with a schema-aware validator before the JSON reaches a strongly typed consumer.
If you want to inspect the output before shipping it, run it through a JSON validator to confirm it parses, then a JSON formatter to lock in consistent indentation. Both steps run locally and let you catch stray commas or mismatched braces before the configuration reaches your application.
Why Values Stay as JSON Strings
Java Properties is a string key-value model: there is no Boolean, no integer, no date inside the table. Automatic type inference — the kind a tool might add to be helpful — can destroy identifiers, formatting, and application-specific meaning. A version string like 001 should not silently become the integer 1. A configuration flag spelled true is still a string until your application explicitly parses it. A date literal like 2026-07-20 is just ten characters, and converting it to a JSON date would be a guess, not a fact.
| Source text | Output | Why |
|---|---|---|
| true | "true" (string) | Properties never store a Boolean; converting would change application meaning |
| null | "null" (string) | A literal null in JSON would mean "missing", which is the opposite of a defined string |
| 001 | "001" (string) | Leading zeros carry meaning in version strings and identifiers |
| 1.5 | "1.5" (string) | Number inference would change formatting; the source is authoritative |
| 2026-07-20 | "2026-07-20" (string) | Date inference is application-specific and outside the parser's scope |
Type conversion belongs later in your pipeline, against an authoritative configuration schema that already knows what shape the application expects. The converter's job ends the moment the keys and values are faithfully represented as strings; everything else is downstream.
What the Converter Does Not Do
The converter models the load(Reader) character-based path and explicitly excludes a long list of features that show up in surrounding Java tooling. It does not emulate load(InputStream)'s ISO-8859-1 byte decoding, so if you have a legacy Latin-1 properties file you must decode it to Unicode before pasting. It does not evaluate defaults chains from a second Properties argument, does not parse XML properties, and does not interpolate environment variables, Spring profiles, encrypted secrets, or framework-specific placeholders. Those features belong to the libraries that load the file at runtime, not to a format-faithful parser.
The bounds are concrete: up to 500,000 input characters, up to 20,000 logical entries after deduplication, and up to 2,000,000 output characters. A boundary failure returns no partial JSON, so a paste that exceeds the input cap will not produce a half-written object that you have to clean up manually. If you routinely work with very large properties files, splitting them before conversion is safer than hoping the converter will silently truncate.
Security is part of the design. Because the conversion runs in the browser, the text never travels to a server. That does not make the output safe to share — pasted secrets should never reach an untrusted destination in the first place — but it does mean the converter itself does not add a new transmission risk to your workflow.
Validate the JSON Before You Use It
Once you have the JSON in hand, two quick checks catch most integration problems. First, confirm it parses with a JSON validator that reports line and column for any syntax error. Second, confirm the set of required keys matches what your application's contract expects; a missing database.url in the output usually traces back to a comment or a typo in the source, not to a parser bug.
If you are feeding the JSON into a strongly typed consumer — a C# object model, a Rust struct, a typed configuration class — remember that every value will arrive as a string and your code is responsible for the conversion. Skipping that step is how a configuration flag that was supposed to be false ends up truthy in production because the string "false" is not the Boolean false. Document the schema on the receiving side, and the round-trip from .properties source to typed application stays predictable.
For more on catching malformed JSON early, the guide on how to check if your JSON format is correct walks through practical validation patterns you can apply right after conversion.
The Properties to JSON Converter is a deliberately small tool: it reads one well-defined format and writes one well-defined format, with the same edge cases the Java specification describes. If your input is Java .properties text and your output needs to be JSON, the conversion is three paste-and-compare steps, and every limit is documented up front so you can plan around them.