App Store keyword localization: 100 characters per locale

App Store keyword localization means filling a separate, hidden 100-character keyword field for every language you add in App Store Connect, with terms people in that market actually search for. Each storefront searches more than one localization: Apple's own table shows the US App Store supporting English (US) plus nine other languages, and Apple says users can find your app with localized keywords in every storefront that supports that language. Get the field right per locale, and the extra locales become extra keyword space. Get it wrong and you waste characters, or show the wrong listing to native speakers.

How the App Store keyword field works

The keyword field is a comma-separated list of up to 100 characters, and nobody but Apple's search index sees it. The rules, from Apple's search guidance and product page guide:

• 100 characters total, commas included. Apple's App Store Connect property reference words it as "up to 100 bytes of content", and its developer guides say 100 characters. More on that difference below.
• Commas, no spaces. Property,House,Real Estate is Apple's own example. A space after a comma is a wasted character. A space inside a phrase is fine.
• Don't repeat words from your app name, subtitle or category. Those are already indexed. Apple's reference also notes your app is searchable by its name and your company name.
• Plurals count as duplicates. Apple's example is "climbs" and "climb". Keep one form.
• Skip filler and generic words like "the", "to", "app" and "game", and special characters such as # or @ unless they're part of your brand.
• Each keyword should be longer than two characters, according to the property reference.

Keywords are version metadata, so you can only change them when you submit a new version. Promotional text is the field you can change any time, and Apple says plainly that it doesn't affect search ranking, so don't put keywords there.

For the other fields' limits (30-character name and subtitle, 170 for promotional text, 4,000 for the description), see our App Store character limits table.

What you can't put in the field

App Review Guideline 2.3.7 asks for keywords that "accurately describe your app" and forbids packing metadata with "trademarked terms, popular app names, pricing information, or other irrelevant phrases just to game the system". Apple's search page adds celebrity names, competing app names and terms not relevant to the app, and says improper keywords are "a common reason for App Store rejections". The same rules apply in every locale. A competitor's name in your ko keyword field is still a competitor's name.

Bytes or characters for Japanese, Chinese and Korean

This matters for non-Latin scripts. In UTF-8 a Japanese or Chinese character takes three bytes, so a strict 100-byte limit would leave room for about 33 of them. Apple's search guidance says 100 characters, and that's what most ASO tools and our own validator count. If you're writing a long CJK field, check what App Store Connect accepts before you rely on the full 100.

Which localizations each App Store storefront indexes

Every storefront has a default language and, in most cases, additional supported languages. Apple publishes the full list of 175 countries and regions in App Store localizations. Its Localize app information page explains what that means for search, using French as the example: "Users can search for your app using localized keywords in all countries or regions where the App Store supports French."

Put those two pages together and you get what ASO people call cross-localization: the keyword field you write for one locale is searched in every storefront that lists that language. Here are the storefronts most indie developers care about, copied from Apple's table as of October 2026:

Storefront	Default language	Additional languages
United States	English (US)	Arabic, Chinese (Simplified), Chinese (Traditional), French, Korean, Portuguese (Brazil), Russian, Spanish (Mexico), Vietnamese
Canada	English (Canada)	French (Canada)
United Kingdom	English (U.K.)	none
Ireland	English (U.K.)	none
Australia	English (Australia)	English (U.K.)
New Zealand	English (Australia)	English (U.K.)
Mexico	Spanish (Mexico)	English (U.K.)
Brazil	Portuguese (Brazil)	English (U.K.)
Germany	German	English (U.K.)
Austria	German	English (U.K.)
Switzerland	German	English (U.K.), French, Italian
France	French	English (U.K.)
Belgium	English (U.K.)	Dutch, French
Netherlands	Dutch	English (U.K.)
Spain	Spanish (Spain)	Catalan, English (U.K.)
Italy	Italian	English (U.K.)
Sweden	Swedish	English (U.K.)
Japan	Japanese	English (US)
China mainland	Chinese (Simplified)	English (U.K.)
Hong Kong	Chinese (Traditional)	English (U.K.)
Taiwan	Chinese (Traditional)	English (U.K.)
Republic of Korea	Korean	English (U.K.)
India	English (U.K.)	Bangla, Gujarati, Hindi, Kannada, Malayalam, Marathi, Odia, Punjabi, Tamil, Telugu, Urdu
Singapore	English (U.K.)	Chinese (Simplified)
Saudi Arabia	English (U.K.)	Arabic
United Arab Emirates	English (U.K.)	Arabic
Russia	Russian	English (U.K.), Ukrainian
Ukraine	English (U.K.)	Russian, Ukrainian
Türkiye	English (U.K.)	Turkish
Indonesia	English (U.K.)	Indonesian
Thailand	English (U.K.)	Thai
Vietnam	English (U.K.)	Vietnamese

A few things in the full table surprised us:

• English (U.K.) is everywhere. It appears in 172 of the 175 storefronts and is the default in 135 of them. Only the United States, Canada and Japan leave it out. If your primary language is English (US) and you never added an en-GB localization, you're leaving the most widely indexed keyword field empty.
• English (US) is indexed in only two storefronts: the United States and Japan.
• Spanish (Mexico) is the default in 16 Latin American storefronts, from Argentina to Venezuela, and an extra language in the US, Belize and Uruguay. There's no separate Latin American Spanish locale, so es-MX is it.
• India's Indic languages (Hindi, Bangla, Tamil and the rest) only show up in the India storefront. Eleven of the 50 App Store languages, including most of these, were added in March 2026. Our App Store Connect languages list has every locale code.

Some ASO firms publish their own versions of this table from keyword tests, and they don't always match Apple's. AppTweak's cross-localization article, for example, lists English (Australia) as indexed in the UK, where Apple lists no additional language. We go with Apple's table, but treat any single row as something to test if a lot rides on it.

Cross-localization: the extra keyword space in the US App Store

Because the US storefront searches ten localizations, a US listing can in theory draw on ten keyword fields, ten names and ten subtitles. That's the reason ASO guides call the US the most valuable cross-localization target. The ten locales and their App Store Connect codes:

Locale	Code	Default language in
English (US)	en-US	United States
Spanish (Mexico)	es-MX	Mexico and 15 other Latin American storefronts
Portuguese (Brazil)	pt-BR	Brazil
French	fr-FR	France, Cameroon, Côte d'Ivoire, Gabon
Chinese (Simplified)	zh-Hans	China mainland
Chinese (Traditional)	zh-Hant	Hong Kong, Macau, Taiwan
Korean	ko	Republic of Korea
Russian	ru	Russia
Arabic	ar-SA	none (additional in 16 storefronts besides the US)
Vietnamese	vi	none (additional in Vietnam)

There are two ways to use this, and only one of them is clean.

The clean way is to localize properly. Spanish speakers in the US search in Spanish, and your es-MX keywords reach them as well as Mexico and the rest of Latin America. Same with zh-Hans, ko, vi and the others: real translations in those fields serve real users in two places at once.

The aggressive way is to stuff extra English terms into a locale you don't otherwise care about, so they rank in the US. This works for search, but every localization is also a listing. Apple shows the French localization to users "whose language setting is in French", so the name, subtitle and description you put in fr-FR are what French-speaking users in the US see, and what everyone in France sees. Put English keywords in es-MX and you've spent the keyword field that 16 Latin American storefronts rely on.

If you do it at all, pick a locale whose default storefronts you have no plans for. vi and ar-SA are the usual candidates because they aren't the default language anywhere. Even then, Vietnamese-speaking users will see whatever listing you put in vi, and Guideline 2.3.7 still applies to every word. We'd rather spend the effort on a real Vietnamese listing, which gets you the same US indexing and an actual Vietnamese audience.

One limit to plan around: AppTweak and Phiture found in their tests that keywords are not combined across localizations. "Budget" in en-US and "planner" in fr-FR won't make you rank for "budget planner". Put both words of a phrase in the same localization's name, subtitle or keyword field.

Why literally translating App Store keywords fails

A keyword list run through a translator gives you dictionary words, not search terms. Three things go wrong.

1. People use a different word. In Japan, a personal budgeting app is a 家計簿 (kakeibo, household account book) app. The literal translation of "budget", 予算, means an allocated budget, the kind a company or a project has. Mexican users talk about their quincena, the twice-monthly pay, where a translator gives you "cheque de pago" for "paycheck".
2. Word length changes. German compounds and Romance-language phrases run longer than English, so a 98-character English list rarely fits after translation. Chinese and Japanese often go the other way and leave half the field unused.
3. The rules break. A translated term often repeats a word that is already in your translated name or subtitle, so it's indexed twice and wastes space. Translation also produces plural and singular pairs that Apple treats as duplicates.

We start every locale with a translation, then research it like a new market:

• Read the competition in that storefront. Open the top apps in your category on apps.apple.com/jp/, /de/, /mx/ and so on. Their names and subtitles are indexed, so they show you which terms local developers have bet on.
• Check Apple Ads search popularity. Apple Ads keyword recommendations show search popularity on a 1 to 5 scale and can be filtered by country or region.
• Ask a native speaker to read the list once. Ten minutes catches the terms nobody actually types.
• Don't translate your brand words. If people search your app's name in English, keep it in the name.

Deciding which markets deserve this effort first is its own question; we cover it in which languages to localize your app into.

A worked example with real character counts

Take a fictional budgeting app with this English (US) listing:

• Name: Coinpath: Budget Planner (24 characters)
• Subtitle: Expense tracker & bill alerts (29 characters)

Indexed already: coinpath, budget, planner, expense, tracker, bill, alerts.

A typical first draft of the keyword field:

budget app, expense tracker, money manager, budgets, finance, bills, savings, spending tracker, money

That's 101 characters, one over the limit. Worse, only five words in it are new: money, manager, finance, savings, spending. Written compactly they take 38 characters (money,manager,finance,savings,spending). The other 63 characters are spaces after commas, "app", words from the name and subtitle, the plurals "budgets" and "bills", and "money" a second time.

The cleaned-up version:

money,manager,finance,spending,savings,goal,paycheck,debt,wallet,cash,income,family,receipt,payday

98 characters, 14 new words, no repeats. "money" and "manager" still work as the phrase "money manager" because both words sit in the same localization.

Now the Spanish (Mexico) listing. A translated name and subtitle:

• Name: Coinpath: Presupuesto (21 characters)
• Subtitle: Control de gastos y ahorro (26 characters)

The keyword field skips presupuesto, gastos and ahorro because they're in the name and subtitle:

dinero,finanzas,quincena,deudas,cuentas,ingresos,metas,familia,recibos,mensual,pagos,efectivo,sueldo

Exactly 100 characters. Per Apple's table, these words are searched in Mexico, the 15 other storefronts where Spanish (Mexico) is the default, and in the United States, Belize and Uruguay as an additional language. Treat the list as a starting point to check against search popularity, not a finished field.

And a Japanese field, with 家計簿 in the Japanese name so it isn't repeated here:

節約,貯金,支出,収入,レシート,固定費,夫婦,共有,お金,管理

That's 32 characters and 78 bytes. Japanese packs a lot of meaning into few characters, so the field has room for another dozen terms. It also shows why the bytes wording in Apple's reference matters: at three bytes a character, a field this short is already most of the way to 100 bytes.

Loci's keyword editor runs these checks per locale, flagging a field over 100 characters, duplicate terms and spaces after commas before anything is pushed to App Store Connect.

Checklist for every localized keyword field

• 100 characters or fewer, commas without spaces.
• No word that's already in that locale's name, subtitle, developer name or category.
• One form per word: singular or plural, not both.
• No "app", no filler words, no competitor names or trademarks in any language.
• Terms researched in that storefront, not only translated.
• Both words of a target phrase in the same localization.
• An en-GB localization with its own keywords, since 172 storefronts support it.
• Before using a locale for extra keyword space, check which storefronts show it as their default language, and remember that its native speakers will read that listing.

For the rest of the listing, from screenshots to What's New, start with our App Store localization guide.