Free tool

Convert .strings to JSON

iOS on one side, i18next or next-intl on the other. Both directions, and values with semicolons in them survive.

Runs in your browser. No account, no upload, nothing leaves your machine.

.stringsJSON

Runs in your browser. The file is never uploaded.

The parser most .strings converters get wrong

A .strings file looks like it can be read with a split on the semicolon. It cannot: semicolons, equals signs and quotes appear inside real values all the time. Prix: 5 €; TTC. becomes two broken lines under a naive parser, and you only find out when the app shows half a sentence. This reader treats a value as a run of characters that are neither quote nor backslash, or a backslash followed by anything, which is the same rule Foundation uses. It also resolves \U escapes from older files and keeps /* block comments */ as translator notes.

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. Going to JSON, the block comments above each entry are dropped, because JSON has no place for a comment. Swap to the other direction and comments come back if the source had them. Nested JSON objects flatten onto dotted keys, which is exactly what an iOS key looks like anyway.

How it works

  1. Step 1

    Drop the file in

    Drag your .strings onto the left box, pick it with the file button, or paste the text. Nothing is uploaded. The conversion runs in this tab.

  2. 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.

  3. 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.

Create account

€19 per month incl. VAT, cancellable monthly.

Questions

What happens to my dotted keys?
By default they become nested JSON objects, so settings.title turns into a settings object with a title inside it, the shape i18next and next-intl want. Uncheck the box under the output to keep them as literal flat keys.
Do format specifiers survive?
Yes. %@, %lld, %1$s and %d come out byte-identical. Placeholders are the single most common way an automated conversion breaks an app: a renumbered %1$s crashes at runtime rather than showing wrong text.
Can it read a file exported from Xcode?
Yes, including the /* No comment provided by engineer. */ blocks Xcode writes above every entry. If you exported XLIFF instead of .strings, use the XLIFF viewer.
Is anything uploaded?
No. The conversion is JavaScript running in this tab, and it keeps working with the network off.

Other converters