{"id":796,"date":"2026-10-09T13:55:00","date_gmt":"2026-10-09T11:55:00","guid":{"rendered":"https:\/\/grindloop.io\/blog\/?p=796"},"modified":"2026-10-08T18:32:56","modified_gmt":"2026-10-08T16:32:56","slug":"string-format-locale-numberformatexception","status":"publish","type":"post","link":"https:\/\/grindloop.ai\/blog\/string-format-locale-numberformatexception\/","title":{"rendered":"String.format Locale Bug: Why “1234,50” Throws NumberFormatException on Android"},"content":{"rendered":"

A String.format locale bug turns a price like 1234.50 into “1234,50” on a German phone. On an Egyptian Arabic phone it becomes “\u0661\u0662\u0663\u0664\u066b\u0665\u0660”. Then toDouble()<\/code> throws NumberFormatException<\/code>. Two causes stack up. First, \"%.2f\".format(x)<\/code> with no locale argument formats with the device’s default locale. That locale picks the decimal separator and even the digit characters. Second, every parser on the other end is locale-blind. toDouble()<\/code> and the server’s JSON parser accept only ASCII digits and a dot. So the string is correct for a human and unreadable for a machine. The bug ships because developer machines, emulators and CI usually run in en-US, where both sides agree. The fix is to never send a localized string to a machine. Build wire values with BigDecimal.toPlainString()<\/code> or Locale.ROOT<\/code>. Format with the user’s locale only for text on screen.<\/p>\n\n

A checkout body that works in the US and fails in Berlin and Cairo<\/h2>\n\n

The running example is a checkout screen. The cart holds its total as a Long<\/code> of cents. That’s the right call for money. The repository turns that total into a request body for the payments API. A receipt cache later reads the amount back out of the same body. Here is the code, cut down to the two functions that matter.<\/p>\n\n\n

import java.util.Locale\n\ndata class Cart(val totalCents: Long)\n\nfun buildChargeBody(cart: Cart): String {\n    val amount = \"%.2f\".format(cart.totalCents \/ 100.0)\n    return \"\"\"{\"amount\":\"$amount\",\"currency\":\"EUR\"}\"\"\"\n}\n\nfun parseAmount(body: String): Double {\n    val raw = Regex(\"\\\"amount\\\":\\\"([^\\\"]+)\\\"\").find(body)!!.groupValues[1]\n    return raw.toDouble()\n}\n\nfun main() {\n    val cart = Cart(totalCents = 123450)\n    for (tag in listOf(\"en-US\", \"de-DE\", \"ar-EG\")) {\n        Locale.setDefault(Locale.forLanguageTag(tag))\n        val body = buildChargeBody(cart)\n        val parsed = runCatching { parseAmount(body) }\n        println(\"$tag  $body  -> ${parsed.getOrElse { it.toString() }}\")\n    }\n}<\/pre>\n\n\n
Locale.setDefault<\/code> stands in for the phone’s language setting. Compiled with kotlinc<\/code> 2.4.20 and run on a JDK 27 JVM, it prints this:<\/p>\n\n\n
en-US  {\"amount\":\"1234.50\",\"currency\":\"EUR\"}  -> 1234.5\nde-DE  {\"amount\":\"1234,50\",\"currency\":\"EUR\"}  -> java.lang.NumberFormatException: For input string: \"1234,50\"\nar-EG  {\"amount\":\"\u0661\u0662\u0663\u0664\u066b\u0665\u0660\",\"currency\":\"EUR\"}  -> java.lang.NumberFormatException: For input string: \"\u0661\u0662\u0663\u0664\u066b\u0665\u0660\"<\/pre>\n\n\n
The same cart produced three different request bodies. Only the US one survives the round trip. The payments server sees the same strings. Its parser rejects them just like toDouble()<\/code> does, so the charge fails for those users. Locale data comes from CLDR and changes between releases. Android’s exact output can differ by OS version.<\/p>\n\n
The String.format locale default changes the separator and the digits<\/h2>\n\n
Kotlin’s \"%.2f\".format(x)<\/code> is a thin wrapper over Java’s formatter. The Kotlin stdlib docs for format<\/a> say the overloads without a locale use the default locale. On Android, the String.format<\/code> reference<\/a> names it exactly. It uses Locale.getDefault(Locale.Category)<\/code> with the FORMAT<\/code> category.<\/p>\n\n
The Formatter<\/code> reference<\/a> then describes a number localization step. It runs after the digits are computed. Each ASCII digit is shifted to the locale’s own zero digit. The decimal separator is replaced with the locale’s separator. With the ,<\/code> flag, the locale’s grouping separator goes in too. So de-DE<\/code> swaps the dot for a comma. ar-EG<\/code> swaps every digit for an Arabic-Indic one and uses the Arabic decimal separator.<\/p>\n\n
The digit swap is easy to miss. It also hits %d<\/code>, so integers aren’t safe either. Tailscale’s Android app hit exactly this in pull request #41, merged in March 2022<\/a>. Its Java side built internal strings with %d<\/code>. Under an Arabic-numeral locale, the Go side got digits it couldn’t parse. The fix switched those calls to Locale.ROOT<\/code>.<\/p>\n\n
Every parser on the other side ignores locale<\/h2>\n\n
The second cause is the asymmetry. Formatting is localized by default. Parsing is not. The Double<\/code> reference<\/a> defines the accepted input as a Java floating-point literal. That grammar has ASCII digits and a .<\/code> as the decimal point. There’s no locale parameter at all. toDouble()<\/code> on the JVM delegates to it, so \"1234,50\"<\/code> is just invalid input.<\/p>\n\n
The server is in the same position. A JSON number can only use ASCII digits and a dot, per RFC 8259<\/a>. A backend that converts the amount<\/code> string with its own decimal parser behaves like toDouble()<\/code>. Nobody on the server side sees the phone’s locale.<\/p>\n\n
Android’s own Locale<\/code> reference<\/a> describes this exact trap in a section titled “Be wary of the default locale”. It says the default locale is right for presenting data to users and wrong for machine-readable output. It adds that the mistake tends to pass on test devices, because so many developers run en_US. That explains why this bug reaches production. The JVM sets its default locale from the host at startup, per the same reference. Local unit tests run on that JVM. On an en-US laptop, every test passes.<\/p>\n\n
The fix keeps wire values unlocalized and formats only for display<\/h2>\n\n
Split the two jobs. A wire value goes to another program, so it must be identical on every phone. A display value goes to a person, so it should follow their locale. The cart already stores cents, so BigDecimal<\/code> can build the wire string with no formatter involved.<\/p>\n\n\n
import java.math.BigDecimal\nimport java.text.NumberFormat\nimport java.util.Currency\nimport java.util.Locale\n\ndata class Cart(val totalCents: Long)\n\n\/\/ Wire value: same bytes on every device.\nfun buildChargeBody(cart: Cart): String {\n    val amount = BigDecimal.valueOf(cart.totalCents, 2).toPlainString()\n    return \"\"\"{\"amount\":\"$amount\",\"currency\":\"EUR\"}\"\"\"\n}\n\nfun parseAmount(body: String): BigDecimal {\n    val raw = Regex(\"\\\"amount\\\":\\\"([^\\\"]+)\\\"\").find(body)!!.groupValues[1]\n    return BigDecimal(raw)\n}\n\n\/\/ Display value: follows the user's locale on purpose.\nfun displayTotal(cart: Cart, locale: Locale): String {\n    val fmt = NumberFormat.getCurrencyInstance(locale)\n    fmt.currency = Currency.getInstance(\"EUR\")\n    return fmt.format(BigDecimal.valueOf(cart.totalCents, 2))\n}\n\nfun main() {\n    val cart = Cart(totalCents = 123450)\n    for (tag in listOf(\"en-US\", \"de-DE\", \"ar-EG\")) {\n        val locale = Locale.forLanguageTag(tag)\n        Locale.setDefault(locale)\n        val body = buildChargeBody(cart)\n        println(\"$tag  $body  -> ${parseAmount(body)}  shown as ${displayTotal(cart, locale)}\")\n    }\n    println(\"ROOT format: \" + \"%.2f\".format(Locale.ROOT, 1234.5))\n}<\/pre>\n\n\n\n
en-US  {\"amount\":\"1234.50\",\"currency\":\"EUR\"}  -> 1234.50  shown as \u20ac1,234.50\nde-DE  {\"amount\":\"1234.50\",\"currency\":\"EUR\"}  -> 1234.50  shown as 1.234,50 \u20ac\nar-EG  {\"amount\":\"1234.50\",\"currency\":\"EUR\"}  -> 1234.50  shown as \u200f\u0661\u066c\u0662\u0663\u0664\u066b\u0665\u0660 \u20ac<\/pre>\n\n\n
The request body is now the same in all three locales. The receipt cache parses it back as an exact BigDecimal<\/code>, with no Double<\/code> rounding. The screen still shows each user their own format. If a formatter is unavoidable, pass the locale. The last line printed ROOT format: 1234.50<\/code>. Android’s Locale<\/code> reference suggests Locale.US<\/code> for machine output. The DefaultLocale lint check docs<\/a> suggest Locale.ROOT<\/code> for internal strings. Both give ASCII digits and a dot. ROOT<\/code> states the intent more clearly.<\/p>\n\n
Then lock the fix in with a test. Set Locale.setDefault(Locale.forLanguageTag(\"ar-EG\"))<\/code> before the test and restore the old default after it. Assert that the body contains \"1234.50\"<\/code>. The broken version fails that test on any laptop. Turn on the DefaultLocale<\/code> lint warning as well. It flags String.format<\/code> calls with no explicit locale. Firefox for Android’s build tooling got this warning from AGP 9 lint, per Mozilla bug 2050917<\/a>. Its build-metrics JSON changed with the build machine’s locale. The fix was Locale.ROOT<\/code>.<\/p>\n\n
This is the same class of bug as our Gson release-build post<\/a>. The code is right in the environment you test and wrong in the one you ship.<\/p>\n\n
What to say when the interviewer shows you the German crash report<\/h2>\n\n
This bug fits a bug-squash or debugging round. The prompt is often a crash report with NumberFormatException: For input string: \"1234,50\"<\/code>. It only happens for some users. Our Android debugging interview post<\/a> covers how that round is scored. Here is the explanation to give.<\/p>\n\n
    \n
  1. Read the input string. A comma where a dot should be points at locale, not at bad data from the server.<\/li>\n
  2. Name the first cause. String.format<\/code> with no locale uses the device’s default FORMAT<\/code> locale. It localizes the decimal separator, the grouping separator and the digits themselves.<\/li>\n
  3. Name the second cause. toDouble()<\/code> and the server only accept ASCII digits and a dot. The formatter is localized and the parsers aren’t.<\/li>\n
  4. Explain why tests missed it. The JVM default comes from the host. The team’s machines run en-US.<\/li>\n
  5. Give the fix. Build wire values with BigDecimal.toPlainString()<\/code> or an explicit Locale.ROOT<\/code>. Use NumberFormat<\/code> with the user’s locale only for display.<\/li>\n
  6. Offer the guard. Add a unit test under an Arabic or German default locale. Keep the DefaultLocale<\/code> lint check on.<\/li>\n<\/ol>\n\n
    Point 2 carries the most weight. Mentioning the Arabic digits shows you know that %d<\/code> is affected too. A comma-to-dot patch can’t fix that.<\/p>\n\n
    Four fixes that pass the German test and break somewhere else<\/h2>\n\n
    Each of these was run against the same JDK as above.<\/p>\n\n