Google Play character limits for every listing field
Three fields, three limits:
| Field | Limit | Indexed for search | Needs a new release to change |
|---|---|---|---|
| App name (title) | 30 | Yes | No |
| Short description | 80 | Yes | No |
| Full description | 4,000 | Yes | No |
| Release notes ("What's new") | 500 | No | Yes |
Play is the simpler of the two stores on paper and the harder one in practice, because all three of your text fields feed search. There is no hidden keyword box to hide your ugly terms in, which means every keyword you want has to survive being read by a human.
Every limit is per language. A listing in six languages has six independent 30-character titles and six 4,000-character full descriptions, and they are edited and saved separately.
What each field is for
App name, 30 characters. The title on the store listing, in search results and under the icon. Same budget as the App Store, so a cross-store name that fits one fits the other. It is indexed, and it is the strongest single signal you control.
Short description, 80 characters. The line shoppers see before tapping "read more", and the only body copy that appears without an interaction. Indexed. Eighty characters is tight enough that it wants to be one clear sentence, not two clauses joined by a semicolon.
Full description, 4,000 characters. The whole pitch, and unlike Apple's description, it is indexed. That single difference drives most of the divergence between a good App Store listing and a good Play listing.
Release notes, 500 characters. Attached to a release, not to the listing. This is the field that trips up teams who assume everything lives in one place, and it is covered properly below.
The one difference that changes everything
Apple indexes the app name, the subtitle and a hidden 100-character keyword field. Play indexes the title, the short description and the full description.
So on the App Store your description is sales copy that search ignores. On Play the same 4,000 characters are both sales copy and your entire keyword surface. There is nowhere else to put a term.
This is why the same app often needs genuinely different copy per store rather than a copy-paste. On Play, a phrase you want to rank for has to appear in text a person will read, phrased in a way that does not embarrass you.
Repetition, and where the line is
Because the full description is indexed, the obvious move is to repeat your target phrase twenty times. Play's Metadata policy prohibits keyword stuffing and repetitive text in store listings, and enforcement is a policy action against the listing rather than a validation error at upload time.
The practical version: write the phrase where it reads naturally, in the title if it fits, in the short description if it is your main term, and two or three times across the full description in different sentences. If you would not say it out loud to a user, it is stuffing.
There is no published repetition threshold, and anyone who quotes you one is guessing.
Formatting and emoji
Play's full description accepts a small amount of HTML: line breaks, bold, italic and lists, depending on where you author it. The Console renders it; the API accepts the same markup in the fullDescription field.
Emoji are the more consequential rule. Play's Metadata policy restricts emoji, emoticons and repeated or unusual punctuation in the app name, icon and developer name, and treats promotional or performance claims there as a violation. Emoji in the full description are common and are not the same problem.
Two counting caveats that matter more than they should:
- Limits are characters, not bytes, so a Japanese title gets the same 30 characters as an English one, which is considerably more meaning per character.
- One emoji is frequently more than one character to a counter. A flag or a skin-toned emoji can be four or more. If you insist on one, leave headroom rather than proving a point at exactly 30.
Release notes live somewhere else entirely
This is the part that catches people mid-launch.
Your title, short description and full description belong to the store listing. You can edit and publish them without building anything. No APK, no AAB, no rollout.
Release notes belong to a release. They are attached to the version you are rolling out, and changing them after the fact means either editing the release while it is still in a track or shipping another one.
The consequence is the opposite of Apple's, where the description is version-bound and the promotional text is free. On Play the descriptions are free and the release notes are pinned. If you write "Now with dark mode" into your full description and the release fails, the listing is already claiming a feature nobody has.
What happens when you go over
The API rejects the value. The push fails with a validation error naming the field, and because listing updates are submitted per language, a single overlong German title can fail an otherwise clean multi-language update.
Anything generating this copy for you should clamp to the limit before it talks to Play, and clamp after generation rather than trying to constrain the writing. AI-written copy has a persistent habit of producing an 82-character short description that reads perfectly.
Spending 30 + 80 + 4,000
A workable order of operations:
- Title. Strongest term plus the brand, if both fit in 30. If they do not, the brand wins and the term moves down.
- Short description. One sentence naming what the app does, containing your second term. Written for a human who is deciding whether to scroll.
- Full description. First two lines do the selling, because that is roughly what shows before the expand. The rest carries the terms you could not fit above, spread across real sentences.
- Release notes. Name the thing you actually fixed. "Bug fixes and performance improvements" is the most-read piece of nothing in software.
Then check the whole thing back against your keyword list, because on Play a term that appears in none of the three fields is a term you are not competing for at all.
AppSubmit enforces each of these limits in the editor and clamps anything the AI writer overshoots, but the table at the top is the whole specification. A character counter does the same job.