Where the 155-character rule comes from
It is a working average, not a limit. Someone measured a batch of results, found the cut usually landed near 155 characters, and the number spread because it is easy to remember. What Google actually does is render the description in a specific font at a specific size inside a container of a specific width, then drop whatever does not fit.
The practical consequence: character count and rendered width disagree constantly. A description of 150 narrow characters fits. A description of 138 characters with several capital M and W does not. If you have ever shipped a snippet that looked correct in your CMS and appeared chopped in search, this is why.
How we measured this
Everything below comes from one fetch: on 2026-09-25 we requested https://<domain>/ for 78 hand-picked domains spanning news, commerce, SaaS, developer tooling, social, education, finance and government. 59 came back as real homepages — the other 19 were bot walls, JavaScript shells and timeouts. 57 of the 59 ship a meta description.
One of those 57 served a Chinese-language variant to our IP address and was dropped from the measurements that depend on English words, leaving 56 descriptions. We decoded HTML entities before counting anything, because counting & as five characters inflates every number in the set.
Length alone was already published in our SERP snippet survey (median 131 characters, interquartile band 114 to 150). What follows is the part that survey did not measure: where the sentences fall, how wide the text actually is, and whether the description agrees with the page it describes.
The two widths that matter
Desktop results render the description at roughly 14px in a container around 600px wide. Mobile is narrower — meaningfully narrower, not marginally. A description tuned exactly to the desktop limit will be cut on a phone, and most of your traffic is on a phone.
The safe approach is to aim at the mobile limit, not the desktop one. Put the part that must survive in the first 120 characters and treat everything after that as optional elaboration.
Finding 1: the cut usually lands in the middle of a sentence
A truncation is only ugly when it lands inside a sentence. If your description is three short sentences and Google cuts after the second one, the snippet still reads as finished. We measured where the first sentence ends in each of the 56 descriptions: minimum 14 characters, 25th percentile 70, median 115, 75th percentile 137, 90th percentile 159, maximum 186.
Set that against the two cut points people actually plan for. 25 of 56 (45%) do not finish their first sentence until after 120 characters, so a mobile cut lands mid-sentence. 8 of 56 (14%) run past 155, which is where the desktop cut usually falls.
The structural reason is that most descriptions are one sentence. 30 of 56 (54%) contain no sentence-ending punctuation until the final full stop, which means there is no earlier boundary for a snippet to end on — whatever width Google has available, the text is cut wherever the pixels run out. A further 5 (9%) carry no terminal punctuation at all, not even at the end.
The cost is smaller than it sounds, which is the useful part. If every description were cut at exactly 120 characters, the median description would lose 9% of its characters. The distribution is lopsided rather than uniform: a quarter of the set loses nothing at all, while the worst case loses 422 characters. So the goal is not to shorten everything — it is to make sure the sentence that carries the meaning finishes before the cut.
Finding 2: character count is not the same as rendered width
We cannot measure the pixel width Google renders at, and anyone who claims a number for it is guessing. What we can measure is one of its inputs: how much of the text is capitalised. Capitals and acronyms are visibly wider than lowercase, and they concentrate in exactly the descriptions that are full of product names.
Across the 56 descriptions, the share of letters that are uppercase runs from 1% to 16%, with a median of 3.5% and a 90th percentile of 8.9%. The densest is developer.mozilla.org at 16% — "The MDN Web Docs site provides information about Open Web technologies including HTML, CSS, and APIs…" — followed by searchenginejournal.com at 11% and semrush.com and netflix.com at 10%. The sparsest are forbes.com, twitch.tv, x.com, wise.com and go.dev, all at 1%.
Among the 42 descriptions that are 155 characters or shorter — the ones whose author already did the right thing by the conventional rule — 10 (24%) sit in the top quarter for capital density. Those are the descriptions where a character counter says "fits" and the rendered result is widest. It is a minority, and it is not a reason to rewrite on principle; it is a reason to stop trusting the counter alone and look at a rendered preview.
Finding 3: your description and your page rarely agree
Google substitutes a sentence from your page when it thinks that sentence answers the query better. That decision has an input we can measure: how much vocabulary the description shares with the text a crawler actually finds on the page.
We compared each description against the page's own <h1> plus its first two paragraphs, counting only content words of three characters or more. 19 of 56 pages (34%) had no extractable body text at all in the initial HTML — JavaScript-rendered homepages where there is nothing for Google to substitute from, and therefore nothing protecting your description from being the only candidate. On the 37 pages where we could extract text, the median overlap was 18% of the description's content words. 20 of 37 (54%) shared less than a fifth of their vocabulary; only 5 (14%) reached 50%.
Read that carefully, because it is not automatically a defect. rust-lang.org writes "A language empowering everyone to build reliable and efficient software" while the page opens with "Rust is blazingly fast and memory-efficient" — the same product, almost no shared words, and both are good copy. What the number shows is that descriptions are written separately from page copy, by different people, at different times. Every description written that way is a description Google has a reason to replace.
Finding 4: one description in six opens with a generic verb
We checked what the 56 descriptions start with. 10 (18%) open with a verb or phrase that could belong to any site on earth: Shop (2), Get (2), Try, Join, Build, Discover, The official, Welcome to. Only 2 (4%) use an exclamation mark.
That is lower than expected, and it is the one place where this sample looks better than the folklore suggests. The failure mode we were looking for — descriptions that are really keyword lists — did not survive checking. Our first pass flagged 27 of 56 (48%) as "looks like a keyword list" using a comma count, and printing them proved the metric was wrong: nearly all were ordinary prose containing a list ("Latest news, sport, business, comment, analysis and reviews"). We dropped the number rather than publish it, which is worth mentioning because the same broken heuristic ships in a number of SEO audit tools.
When Google ignores your description entirely
Often. If Google decides a sentence from your page body matches the query better than the description you wrote, it substitutes that sentence. This is normal behaviour and not a signal that anything is wrong.
You cannot force it to use your text. What you can do is remove the reason to substitute: write the opening sentence of the page so that it would work as a snippet on its own, and keep the meta description aligned with what the page actually says. When the two agree, there is nothing to gain by swapping.
What is not worth doing
Do not stuff the description with keyword variants. Descriptions are not a ranking factor; their entire job is to earn the click. A description written for a machine reads like it was written for a machine, and gets skipped.
Do not write one description and reuse it across a template. Duplicate descriptions are not penalised, but they make every page in a set look identical in the results, which costs you the clicks that a specific sentence would have earned.
A working method
Draft the description last, after the page is written. At that point you know what the page actually delivers, and you can say it in one sentence without guessing. Descriptions written before the page exists tend to describe the page you intended rather than the one you shipped.
Then put the sentence into a preview and check where it lands. If the important part is past the mobile cut, move it forward rather than trimming the tail — the end of a description is the cheapest thing to lose.
One more thing worth doing: read the first sentence of the page body next to the description. If they are far apart, Google has a reason to substitute one for the other. Aligning them is the closest thing to control you have over what gets shown. In our sample the median overlap between the two was 18% of content words, so "far apart" is the normal state, not the exception — and it is cheap to fix.
What to do with this
Finish your meaning before character 120. 45% of the descriptions we measured do not end their first sentence until after that point, so the mobile cut lands mid-sentence. Moving a clause forward is usually enough; you do not have to shorten anything.
Write two sentences, not one. 54% of the sample is a single sentence with no internal break, which leaves Google no sentence boundary to cut at. A short first sentence that stands alone plus a second one that can be dropped is the structure that survives any width.
Treat the character counter as a floor, not a verdict. A quarter of the descriptions that fit inside 155 characters are also in the top quarter for capital density, and those are the ones the counter is most likely to be wrong about.
Write the description from the page's own opening sentence. If the two share vocabulary, Google has less reason to replace yours. This is the only lever you have on substitution, and it costs one pass of editing.
Skip the generic opener. One in six of these homepages still opens with Shop, Get, Discover or Welcome to. Those words are in every competing snippet on the page, so they cost you the only part of the result where you had a choice.
To see where a real cut falls before you ship, the SERP preview tool renders a title and description at Google's desktop and mobile widths, and the meta tag generator emits the title, description and canonical from one input so the three cannot drift apart. If you want the length distribution behind this article, the SERP snippet survey covers all 59 homepages.
Limitations
56 descriptions from 59 homepages of hand-picked, well-known domains. Homepages are the most polished page on any site — the page somebody argued about in a meeting. Article, product and category pages, where descriptions are generated from templates, would almost certainly look worse, and this sample says nothing about them.
We read the initial HTML only. A description injected by JavaScript is invisible to this method, and 19 of 56 pages had no extractable body text at all, which is why the overlap measurement covers 37 rather than 56.
One fetch, from one IP address, on one day. stripe.com served a Chinese variant and was excluded, but the exclusions are only as good as the language detection behind them. uber.com is the visible case: its description in our fetch reads "Uber is finding you better ways to move, work, and succeed in Germany" — a regional variant, not a global one. Any single-location audit has this problem, and ours is no exception.
The 120- and 155-character cut points are conventions, not measurements. We did not measure rendered width and cannot; the capital-density figure is one input to it, not a substitute for it.
Two metrics were dropped rather than published. The keyword-list heuristic flagged 48% of the sample and was wrong on inspection. And "does the description contain the brand" failed the same way it did in our snippet survey: matching the domain's first label fails on any brand spelled differently from its URL.
Reproduce it
The script ships with the site and needs no network. node scripts/survey-serp-snippet.mjs fetches and stores the raw HTML for all 78 domains; node scripts/survey-description.mjs re-derives every number in this article from that stored HTML; --evidence prints the original text of every row we made a judgement about, which is how the two bad metrics above were caught. Share the same domain list with our robots.txt and canonical surveys.