Free tool
Convert .properties to JSON
Java, Spring and Kotlin resource bundles on one side, i18n JSON on the other, including the escape rules that break a naive split.
Runs in your browser. No account, no upload, nothing leaves your machine.
Runs in your browser. The file is never uploaded.
Three rules that make split('=') wrong
The properties format looks like key equals value and is not. The separator can be an equals sign, a colon, or plain whitespace: server.port 8080 is a valid entry. A line ending in a single backslash continues on the next one, with the leading whitespace of the continuation discarded. And the key itself may contain an escaped separator, so a\:b=c has the key a:b. All three appear in real Spring message bundles, and all three are read correctly here. Old files using \uXXXX escapes for non-ASCII are resolved on the way in.
What survives
Converting is easy. Not breaking the file is the hard part.
Every converter that treats a language file as plain text will eventually ship you a crash. These are the three places it happens.
- Placeholders stay placeholders
- %@, %lld, %1$s, {name} and {{count}} come out exactly as they went in. A placeholder that got escaped, renumbered or translated is a crash on the device, not a typo.
- Plural forms stay separate
- Xcode variations, the Android plurals element and gettext msgstr[n] all mean the same thing and all spell it differently. They map onto each other here instead of collapsing into one string. Polish has four forms; all four survive.
- Keys keep their shape
- Nesting, dotted paths, arrays and translator comments carry across wherever the target format has somewhere to put them. Where it does not, the section below says so.
What does not come across
Written down here, because the alternative is finding out in a broken build.
Nothing on the string level, but the output is written as UTF-8 without \uXXXX escaping, the default for ResourceBundle since Java 9. If you are still on an older runtime that reads properties as ISO-8859-1, run the result through native2ascii. Comment lines starting with # or ! immediately above an entry are kept as its translator note; free-floating comments are not.
How it works
- Step 1
Drop the file in
Drag your .properties onto the left box, pick it with the file button, or paste the text. Nothing is uploaded. The conversion runs in this tab.
- Step 2
Read the result
The JSON appears as you type. The counter under the box says how many keys came through, so a file that lost half its content is visible immediately.
- Step 3
Copy or download
Take the text to the clipboard, or download it with the right extension. Swap the arrow to go the other way.
One language file in. 64 languages out.
Converting a format is the part you can do by hand. Translating 3,627 keys into 64 languages without breaking a single placeholder is the part you cannot. On the next release you only pay for the strings that changed.
€19 per month incl. VAT, cancellable monthly.
Questions
- My values contain equals signs. Does that work?
- Yes. The reader splits at the first unescaped separator, so formula=a = b gives the key formula and the value a = b. This is the single most common failure of hand-rolled properties readers.
- Are multi-line values supported?
- Yes. A line ending in an odd number of backslashes continues on the next line. An even number means the value genuinely ends in a backslash, and the entry stops there. That distinction matters and is handled.
- What about \uXXXX escapes in an old bundle?
- They are resolved when reading, so \u00f6 arrives as ö. When writing, plain UTF-8 is used, which is what modern Java expects.
- Can I convert JSON back to a bundle?
- Yes, swap the direction. Separators and whitespace in keys are escaped on the way out so the result parses back identically.