Choose useful terms before trimming the string
List the tasks a target user can complete in the current release. Include the object, audience or context only when it clarifies relevance. Write a short feature reference beside each candidate so an attractive but unsupported phrase can be removed. Keep demand estimates and their sources in a separate research sheet. The counter checks text structure; it has no access to live search-volume estimates or your app's ranking history.
Compare the shortlist with the name and subtitle already entered for the same locale. A repeated word can consume limited space without adding a distinct task. A competitor's name or an unrelated popular term does not become appropriate because spare characters remain. Leave uncertainty in the research record. Review the phrase with a person who speaks the target language before compressing it into a final submission string.
Count the exact draft in two ways
The free checker displays Unicode code-point characters and UTF-8 bytes for your input. For ASCII text those counts agree. For accented letters, non-Latin scripts and emoji they can differ. It also identifies blank comma entries, repeated normalized words and words already present in the entered name or subtitle. These are editing prompts rather than a complete linguistic analysis. It does not identify trademarks, synonyms or every singular-and-plural relationship.
Use the same text that you intend to submit. Spaces, commas and invisible characters can affect the serialized input. Pasting a visually similar string from a different editor can preserve an unexpected space. Review the exact draft after copying it into App Store Connect, especially if you changed the language or punctuation. A local count cannot establish store acceptance; the console remains the final place to validate the metadata.
Remove formatting waste without destroying meaning
Trim whitespace around comma-separated entries and remove accidental empty entries. Keep meaningful spaces inside a multiword phrase where needed. Review exact duplicate words before removing them, since the checker cannot decide the best wording for your audience. Save the previous string when applying changes so the team can trace what was submitted. Do not silently translate or rewrite a phrase merely to make the counter turn green.
Check the title and subtitle as a whole after reducing keyword duplication. A compact field cannot rescue an app name that misstates the product. Avoid using restricted or unrelated terms, category filler and unsupported ranking language. Treat the result as a preparation checklist: length, clarity, relevance and format are different checks. A draft that passes length still needs a person to assess whether each word belongs to the released app.
Track a keyword change by locale and release
Record the old and new metadata, storefront, language, date and the reason for each edit. Keep screenshot changes separate where feasible. Review discovery data together with listing conversion and activation, using the same report definitions and period. Do not assume a movement after publication was caused by a particular term. Store search, competitors and visitor behavior can change while your listing remains the same.
Use the next observed question to refine the shortlist. If people arrive expecting a feature that is not supported, investigate the promise rather than adding more terms. If they understand the task but abandon onboarding, keyword editing is not the only work needed. A keyword field is one part of discoverability, and it should remain consistent with what a person sees in the product page and experiences after installation.
Working example
Illustrative draft: a fictional app named Binder Notes uses the subtitle Keep your collection organized. Its keyword string is cards, binder, cards,,échanges. The checker flags the repeated cards entry, an empty entry and binder overlapping with the name. It shows why échanges contributes more UTF-8 bytes than code-point characters. The owner checks whether the French term belongs in this locale, removes formatting waste and validates the revised draft in the console. These are mechanical editing observations, not evidence that the remaining terms have search demand or that the app will rank for them.
Your next steps
- Choose relevant terms and record their feature support.
- Check both code-point characters and UTF-8 bytes.
- Review duplicate words, empty entries and separator spaces.
- Validate the final locale-specific string in the console.
Questions about this guide
Is the App Store keyword field limited to 100 bytes or 100 characters?
Apple's product-page guide describes 100 characters, while its App Store Connect platform version reference says up to 100 bytes. This checker shows both counts and uses a conservative UTF-8 byte check. Validate the exact localized draft in App Store Connect.
Why can 51 accented letters exceed the byte check?
In the example, each precomposed é uses two UTF-8 bytes. Fifty-one code points therefore occupy 102 bytes. The visual character count and encoded byte count describe different properties of the same input.
Do commas and spaces count toward keyword length?
Yes. The checker counts the exact string, including separators and spaces. It trims spaces around comma-separated entries only in the separate separator-cleaned draft; the original counts remain tied to the text you entered.
Are the counter examples recommended keywords?
No. They are synthetic counting demonstrations. Choose relevant terms from your product and locale research, review the wording and use the final console validation before submitting metadata.
Official sources
Sources checked October 5, 2026. Review the current provider documentation before acting on requirements.
Turn the next test into something useful.
Publish a focused brief on RateMyApp. Credits fund approved private reports; public store reviews are voluntary and unrewarded.
List your app for feedback