To put Java .properties values into C# class properties, convert the file to JSON that follows java.util.Properties.load(Reader) parsing rules, then deserialize that JSON into your C# model with System.Text.Json or Newtonsoft.Json. The first step is the one most C# developers get wrong, because .properties is not a one-key-per-line format: it allows comments, blank lines, logical-line continuations with backslashes, three separator styles, and escape sequences that include \uXXXX Unicode codes. A naive split on newlines or a quick regex will produce JSON whose values disagree with what the original Java application would have read, and the wrong character in a C# string property can break a downstream lookup, a localization lookup, or a connection string. Treating the conversion as a deliberate two-stage pipeline — properties parsing first, then C# binding — keeps both halves verifiable on their own. You can diff the JSON against the source's unique-key count, then validate the resulting C# model against the consuming application's contract before you ship.
Why a C# developer would start from a .properties file
C# and .NET applications often receive configuration from systems that were originally Java. Localization resource bundles are a common case: a translator hands you a messages_en.properties, messages_fr.properties, or messages_ja.properties file and the rest of your stack already expects JSON for ASP.NET Core's IConfiguration binding, Azure Functions input bindings, or a strongly typed options class. Legacy integration scenarios are another: a partner exposes a Java service that still emits its connection details as .properties text, and the C# side needs to consume them. Build-pipeline outputs are a third: an Android or Spring Boot build step produces a .properties artifact that a downstream .NET tool reads. In each of these cases the C# application does not want to reimplement Java's escaping rules; it wants clean JSON it can hand to JsonSerializer.Deserialize<T> and read straight into its own string properties.
How .properties parsing turns into JSON that C# can bind
The Properties to JSON Converter models the character-based java.util.Properties.load(Reader) method directly in the browser. It does not upload your text, does not contact a Java process, and does not try to invent load(InputStream)'s ISO-8859-1 byte decoding on top of Unicode text. The browser already supplies Unicode code points, so what you paste is what gets parsed. The conversion reads logical lines by joining any physical line whose preceding run of backslashes has odd length, skips lines whose first non-whitespace character is # or !, ignores blank lines, and finds the first unescaped separator — equals, colon, or properties whitespace — to split each logical line into a key and a value. Every value is then JSON-serialized as a string, and the intermediate record uses a null prototype so that keys such as __proto__, constructor, and toString remain ordinary own data instead of inherited prototype members.
The result is a pretty JSON object whose unique-key count you can compare against the source. If a .properties file declares app.name three times with different values, only the last value appears in the JSON, which matches Java's table-replacement semantics. Comments, the original separator style, and the exact physical-line ordering are not represented in JSON, so this is not a reversible formatter. When order or comments matter, keep the source file beside the JSON.
Load .properties files into C# class properties: the steps
- Open the Java .properties file in a text editor, copy its full text (CRLF, LF, or CR line endings are all accepted), and paste it into the converter. Include any comments and continuation lines — do not pre-clean the input.
- Convert and compare the unique-key count printed by the tool with the count of distinct keys in the source. If the numbers differ, the most common causes are unescaped equals signs inside keys, missing continuations, or duplicate keys that the Java runtime would also have collapsed.
- Copy the pretty JSON, then run it through a JSON validator to confirm structural correctness before you deserialize it into your C# class with JsonSerializer.Deserialize<AppConfig>(json) or JsonConvert.DeserializeObject<AppConfig>(json). Every property on the C# class will receive a JSON string — never a boolean, number, or null — unless your code converts it later.
- Validate types and required keys against the consuming application's contract. Convert "true" to bool, "123" to int, or "2026-07-20" to DateOnly only after the JSON lands in C# and only against an authoritative configuration schema you control.
A minimal C# model that pairs with this pipeline looks like a plain class decorated with property names that mirror the keys, for example public string AppName { get; set; } bound to app.name, or a Dictionary<string, string> when the keys are open-ended. The deserializer reads the JSON strings straight into those properties; type coercion happens in your code, not in the converter.
Escape rules that change what your C# string properties hold
Java's escape processing is small but precise, and it is the most common source of subtle mismatches between a source .properties file and the C# string property that ends up holding the value. The following table lists the escapes the converter recognizes and the character each one produces.
| Java escape | Decoded character | Practical effect in a C# string property |
|---|---|---|
| \t | Tab (U+0009) | Triggers tab-aware UI rendering or splits on \t in a CSV-style value. |
| \n | Line feed (U+000A) | Survives as a real newline inside a multi-line C# string. |
| \r | Carriage return (U+000D) | Appears as CR, often paired with \n for CRLF. |
| \f | Form feed (U+000C) | Preserved as form feed; do not strip it before binding. |
| \\ | Backslash (U+005C) | Needed for Windows paths like C:\\app\\bin. |
| \uXXXX | Unicode code point from exactly 4 hex digits | Decodes to the literal character; \u0041 becomes A, \u00e9 becomes é. |
| \ before any other character | The character after the backslash, with the backslash removed | Matches Java's documented behaviour; octal and a backspace escape are not invented. |
Worked example for one logical line:
Input (Java escape form): greeting=Hello\u0020World
After decoding: greeting=Hello World (the \u0020 is exactly 4 hex digits representing U+0020, the space character).
JSON output: { "greeting": "Hello World" }
C# property: public string Greeting { get; set; } now holds "Hello World" after deserialization.
A malformed Unicode escape, such as \u12 with fewer than four hex digits, returns an error from the converter instead of being copied as plausible data. This guard matters because copying \u12 verbatim into a C# property would later round-trip through JsonSerializer as the literal text \u12, not as a Unicode code point, and downstream consumers would disagree with the original Java reader. For a deeper read on the rules themselves, the Properties to JSON escape rules and duplicate-key handling guide walks through the same edge cases with concrete fixtures.
Why every value stays a JSON string
The converter deliberately refuses to convert true to a JSON boolean, 123 to a JSON number, null to a JSON null, or 2026-07-20 to any date form. Java Properties is a string-to-string model: every value the source could hold is text, and the consumer is responsible for interpreting it. A C# property that is declared as int would round-trip correctly whether the JSON contains "42" or 42, but a property declared as string holding a value such as 001 or 1.5 would silently lose its leading zeros or its decimal precision if the converter decided it was a number. The same logic applies to identifier-shaped keys such as order.001: keeping them as strings avoids accidental reordering, accidental zero-padding, and accidental numeric coercion.
The practical rule is to keep the converter as a string-only bridge and convert types in C# against an authoritative schema. When you do need numeric, boolean, or date properties, declare them explicitly on the C# class and let JsonSerializer perform the conversion. When you need to preserve exact spelling, keep the C# property as string and parse it yourself later.
Limits, duplicate keys, and a final validation pass
The converter accepts up to 500,000 input characters, up to 20,000 logical entries, and produces up to 2,000,000 output characters. A boundary failure returns no partial JSON, so a successful response always reflects the full input. The eight external fixtures that ship with the tool cover the three separator forms, escaped spaces, newline and Unicode escapes, continuation lines, and duplicate replacement; additional tests cover comments, empty values, prototype-shaped keys, and malformed Unicode. None of those tests assume ISO-8859-1 byte decoding, defaults chains, XML properties, environment interpolation, Spring profiles, variable expansion, or encrypted secrets — all of those belong to the Java runtime, not to a browser-side converter.
| .properties behaviour | JSON output | Reason |
|---|---|---|
| Comment line starting with # or ! | Omitted | JSON has no comment syntax; the parser strips the line. |
| Blank line | Omitted | Blank lines are not entries. |
| key = value, key: value, key value | { "key": "value" } | Three separator styles normalize to the same JSON output. |
| Line ending with odd backslashes before newline | Joined with the next line | Logical-line continuation per the Java specification. |
| Duplicate key declared multiple times | Last value wins | Matches Java's table-replacement semantics. |
| key with no separator | { "key": "" } | Empty value is still a valid entry. |
Before you replace any configuration in production, compare the resulting JSON's unique-key count with the Java application's behaviour on the same file, run the JSON through a validator to catch trailing-comma or quoting mistakes from manual edits, and confirm that every required key on the consuming C# side is present. Never paste production secrets into an untrusted destination, and never share the copied output casually: the conversion runs locally, so the data does not leave your browser, but downstream copies inherit whatever access the destination grants. With those checks in place, the pipeline — Java .properties to JSON, JSON to C# class properties — gives .NET developers a verifiable path from a legacy format to a strongly typed configuration without reimplementing Java's escaping rules inside C#.
Related reading: Cookie Converter for Beginners: Convert Cookies to JSON.