Your Keyword Field Is 100 Bytes, Not 100 Characters

A limit almost nobody documents correctly

App Store Connect gives you one keyword field per localisation and tells you the cap is 100. Nearly every ASO guide reads that as 100 characters. It is 100 bytes, encoded as UTF-8, and for anyone shipping outside English that difference decides whether half your keywords exist.

We found out the way most studios do: metadata that looked fine in the form came back shorter in the live listing.

What a character costs

UTF-8 is variable-width. The cost per character depends on the alphabet:

A Ukrainian or Greek listing has half the keyword room of the English one. A Japanese listing has a third. The form does not warn you; it accepts the input and the store truncates later, mid-word, wherever byte 101 lands.

Why the naive check fails

The check most teams write is the one that does not work:

`dart // Wrong: counts UTF-16 code units in Dart, characters elsewhere. if (keywords.length > 100) { … }

// Right: measure the encoded form. if (utf8.encode(keywords).length > 100) { … } `

The trap gets worse with anything outside the Basic Multilingual Plane. An emoji is a single visible glyph, often two UTF-16 code units, and four UTF-8 bytes. Three different numbers for one symbol, and only the last one is the one the store enforces.

Budgeting the field

What has worked across our own eight listings:

1. Measure in bytes from the first draft, not at submission. Byte cost is a constraint on the copy, so it belongs in the writing stage. 2. Drop the spaces after commas. The separator is the comma; each space you keep is one byte spent on nothing. Across a full field that is often a whole extra keyword. 3. Never repeat a word already in the app name or subtitle. Apple indexes those fields too. A repeat costs bytes and buys no reach. 4. Budget per storefront, not globally. The same keyword set costs a different amount in every language, so a set that fits in English can overflow in German.

Google Play counts differently — and that catches people too

There is no keyword field on Play. Discovery reads the title, the short description and the full description, which means the constraint moves rather than disappearing:

Play counts characters, so Cyrillic and CJK cost the same as Latin there. The trap is the opposite one: teams who learned to budget bytes for Apple carry the habit over and under-fill Play's fields, or they write one description for both stores and lose the keyword density Play actually indexes.

Two stores, two models. The only safe assumption is that neither field behaves like the other.

What to do about it today

Where this leads

We hit this on our own apps often enough that we built a tool for it. Larko does byte-exact counting as you type, audits listings across storefronts in parallel, and flags rejection risks — including Apple's Guideline 2.3.10, which is the other silent metadata killer — before you submit.

It exists because we needed it. The byte limit is a small thing, and small things are exactly what a submission dies on.