The iOS Keyword Field in 2026: How the 100-Byte Field Works

The iOS keyword field is the most misunderstood surface in App Store Optimization — a private field in App Store Connect that no user sees. Apple allows up to 100 bytes of content, not 100 Unicode characters. That difference matters for Turkish, accented Latin text, CJK scripts, emoji, and any other content whose UTF-8 encoding can use multiple bytes.

This guide separates Apple's documented rules from industry hypotheses, shows how to measure UTF-8 bytes, and provides a before/after example you can adapt and validate.

What the iOS keyword field is

The keyword field is a private, comma-separated input you set per localization in App Store Connect (under your app version's metadata, not on the public product page). Unlike your app name and subtitle, it is not visible to users. Apple's current platform-version reference says you can provide up to 100 bytes, that the app is already searchable by app name and company name, and that those values should not be duplicated in the keyword list.

A few facts worth pinning down:

• It's per localization. Each localization can have its own name, subtitle, and keyword field. Research each storefront separately; do not assume that fields combine into a universal cross-locale keyword pool.
• Every character contributes UTF-8 bytes. Commas, spaces, and letters all consume bytes; multibyte characters consume more than one. Measure the encoded value rather than trusting a JavaScript string length or visual character counter.
• Keep native and web discovery separate. Apple documents the long description as product-page copy that is used for web-engine search results. Lite ASO does not count it as private iOS keyword-field coverage for native search.

Because users do not read it, the keyword field can hold relevant candidate vocabulary that would be awkward in visible marketing copy. Every term still needs to comply with Apple's rules, accurately describe the app, and be validated against measured search observations.

Byte-saving rules and hypotheses

You have up to 100 UTF-8 bytes. There is no fixed number of keywords that fits and no public Apple field-weight formula. Use the following as mechanics or testable tactics, not guarantees:

1. Remove optional spaces after commas. tracker,budget,expense uses fewer bytes than tracker, budget, expense.
2. Follow Apple's explicit de-duplication rule. Do not repeat the app name or company name in the keyword list. For overlap with the subtitle or other candidate terms, use measured coverage instead of claiming a guaranteed no-repeat bonus.
3. Do not assume stemming. Singular/plural and inflected-form behavior can vary by language and query. Track both before deciding that one form covers another.
4. Do not assume Apple supplies generic terms for free. Remove irrelevant words, but validate relevant category or intent vocabulary rather than relying on folklore about app, free, new, or best.
5. Treat word recombination as a hypothesis. Single terms can increase the number of combinations you can test, but Apple does not publish a guarantee that every cross-field phrase will rank.
6. Count every byte. Special characters and emoji can consume several bytes. Use them only when they are relevant and supported by evidence, not because they look like one character.

A better rule: spend bytes on relevant candidates, and keep only what measurement supports.

How to test searchable combinations

ASO practitioners often test whether terms across the app name, subtitle, and keyword field can support multi-word queries. Apple does not publish an exhaustive combination algorithm, so treat this as an experiment rather than a rule.

Say your metadata contains these words across the three fields:

• App name contributes: budget
• Subtitle contributes: expense, tracker
• Keyword field contributes: planner, bills, savings

Candidate queries include budget tracker, expense planner, bill tracker, and savings planner. Track those exact queries for the intended storefront before and after a controlled metadata change. A compact list of single terms creates more hypotheses within the byte limit; it does not guarantee that every combination is indexed or ranked.

Duplication has a clear opportunity cost: the repeated bytes cannot hold a new candidate. What it does not give you is knowledge of Apple's private weighting. Prefer broader relevant coverage unless your own experiment supports intentional overlap.

If you want the full picture of how the name, subtitle, and keyword field interact across your store presence, our App Store optimization guide covers the broader metadata strategy, and the App Store keyword research guide goes deep on finding the words in the first place.

Single vs broad keywords (and relevance)

Not all words are worth their bytes. Evaluate candidates using separately reported evidence such as relevance, observed search demand, current position, competitor coverage, and confidence. Do not collapse those signals into a supposedly universal multiplication formula. Two failure modes are common:

• Chasing head terms. A generic, ultra-competitive term like game or photo has enormous volume but you'll rank on page 12 for it — and it eats characters that a winnable long-tail term could use. For most apps, broad head terms in the keyword field are a quiet waste.
• Ignoring relevance. High-volume but loosely related words create misleading metadata and poor measurement hypotheses.

The sweet spot is mid-volume, high-relevance, winnable terms — often two-word intents you can assemble from single words. That's where the keyword field earns its keep: it's a place for the specific, high-intent vocabulary your competitors haven't thought to combine.

Use the available byte budget for relevant, measured candidates — research them with Lite ASO.

A worked before/after example

Here's a weak keyword field for a fictional budget and expense tracking app named "MoneyWise: Budget Tracker" with the subtitle "Expense & Bill Planner."

Before (weak — 91 UTF-8 bytes, mostly wasted):

budget, budgeting app, expense, expenses, tracker, money app, free finance app, best budget

What's wrong with it:

• Spaces after every comma — roughly 8 wasted characters.
• budget, expense, and tracker repeat words already in the visible metadata, reducing room for new candidates.
• budgeting app, money app, and finance app repeat app without adding much specificity.
• expense and expenses spend bytes on two forms before measuring whether both are needed.
• free and best are broad promotional terms rather than precise descriptions of the product.

After clearing that overlap, the field can test a wider range of relevant concepts. This is an opportunity-cost observation, not a claim that Apple guarantees indexing for every replacement.

After (candidate set — 93 UTF-8 bytes, every term relevant):

savings,debt,bill,subscription,spending,income,budgeting,finance,wallet,cashflow,receipt,loan

The "after" field carries twelve fresh, relevant candidate terms. It creates testable queries such as bill tracker, debt planner, subscription budget, savings tracker, and spending planner. Track those queries; do not assume that listing the component words guarantees a position.

How to choose what goes in the field

The mechanics are easy; the hard part is deciding which words deserve a slot. This is research, not guesswork. For each candidate keyword you want three numbers:

1. Search volume — is anyone actually searching this term? A perfectly winnable keyword nobody types is worthless.
2. Difficulty / competition — can your app realistically break into the top results, given the apps already ranking?
3. Relevance — does the term describe what your app does? Low relevance hurts conversion even if you rank.

Then prioritize high-relevance candidates with sufficient observed demand and a realistic competitive baseline. Prune terms when evidence says the bytes would be more useful elsewhere; do not automatically remove every plural or phrase across every language. This loop — pull candidates, record evidence and confidence, test, and revise — is where a keyword tool earns its keep.

This is the core workflow Lite ASO is built for: it surfaces keyword volume and difficulty scores, tracks what competitors rank for so you can find gaps, and (via MCP) lets you run the whole research loop straight from ChatGPT or Claude.

Quick checklist

Before you save that field, run through this:

• At most 100 UTF-8 bytes used — do not pad with irrelevant terms.
• No spaces after commas.
• No app-name or company-name duplication, as Apple explicitly recommends.
• No duplicate words inside the field.
• Plural and inflected forms are evidence-based, not removed by default.
• No irrelevant promotional or generic filler.
• Single words versus phrases is a measured hypothesis.
• No special characters or emojis.
• Every word researched for volume, difficulty, and relevance.
• A separate field for each localization you ship.

Once your keyword field is tight, the rest of your product page supports conversion. See our guides on App Store screenshots in 2026 for the visuals, and App Store vs Google Play in 2026 if you're optimizing for both stores at once — Google Play has no private keyword field and says app descriptions are among the factors search considers, which changes the approach.

The iOS keyword field rewards discipline: up to 100 UTF-8 bytes, no irrelevant padding, and every term earning its place through research.

Stop guessing — build a byte-valid candidate set and measure it. Research demand, competition, and relevance with Lite ASO.