Meta Description Checker — Live Length vs. the ~160 Snippet

A budget stated as of mid-2026 — and what it is not

The meter above checks your draft against 160 characters. That is the only search-snippet figure this site states, and it is stated the way the methodology page states it: ~160 reflects the platform's published rules as of mid-2026, and when Google changes the figure, this page's copy and its preset are updated. What the figure is not is a cap. It is a drafting convention standing in for a behaviour that is not a character count at all: Google cuts snippets by rendered pixel width, so the real boundary moves with the shapes of your letters and, as the note at the foot of this page says, with device and query. That one fact drives everything else here. The companion guide, Truncation and folds: what the checker cannot see, sets it beside Instagram's fold and YouTube's title truncation, and the guides index covers the rest of the site's fine print.

What the checker counts

The count is in Unicode code points, the unit most platforms have in mind when they publish a cap, and every code point costs one: letters, digits, spaces, punctuation, line breaks. An accented letter such as é is one, a CJK character is one, and an emoji such as 🎉 is one — a single code point, not the two UTF-16 units JavaScript needs to store it. Take the draft "Crème brûlée, café au lait and pâtisserie — 24 seats, open from 7am.". The meter reads 68 characters, 92 of 160 remaining. Run the same draft through the engine's letter breakdown and those 68 are 49 letters, 3 digits and 12 spaces, with the remainder spent on punctuation and the dash. The spaces are the part people forget to budget for: each one is a character, and so is a line break pasted in from a document.

The one place that rule needs a second look is a joined emoji. 👨‍👩‍👧 shows on screen as a single glyph, but it is assembled from several code points linked by joiner characters that are themselves invisible, and the meter counts what is present rather than what is drawn: 5 for that one glyph. Platforms do not agree with one another on how to count such sequences, which is one reason the final authority on a borderline draft is always the platform itself rather than a third-party counter. The secondary word count on the stat card detects words with Unicode awareness — a word is a run of letters and digits in any script, and a hyphen or an apostrophe inside the run does not break it — so "step-free" and "it's" are one word each. It is there for orientation; the budget is the character figure.

Why the snippet cut can differ from the count: described, not modeled

Some platform rules run in this site's engine; others are stated on the page but deliberately not simulated. The methodology draws that line where simulation would require guessing at server-side behaviour that cannot be verified from the outside, and Google's pixel-width snippet cut sits on the described side of it — alongside X's weighted counting, Instagram's ~125-character feed fold and YouTube's device-dependent title truncation. Modeled on this page: a code-point count against the 160-character budget. Described, not modeled: where the snippet is actually cut. The checker does not estimate glyph widths, does not render your text in any typeface, and does not know the device or the query, both of which move the cutoff.

The gap is easy to demonstrate. In any proportional typeface a capital W is wider than a lower-case i, yet each is one code point. The drafts "fixed-price window cleaning with insured staff and next-day slots" and "FIXED-PRICE WINDOW CLEANING WITH INSURED STAFF AND NEXT-DAY SLOTS" are the same text in two cases: the meter reads 65 characters for the first and 65 for the second — identical to the character — while on screen the second is plainly the wider line. So the quirk skews the count you see here in both directions. A draft the meter calls safe can still be cut short if its characters run wide, and the cut can equally land later than the budget on a narrow draft; this page cannot tell you which applies to yours. What it can tell you is the margin to a convention, which makes the practical reading one-directional: treat "remaining" as room inside the budget, never as the distance to the cut.

Where the checker stops

The tool is precise about a small job. It counts code points on every keystroke, fills the bar in proportion to the 160-character budget, and switches the display from "remaining" to "over the 160 limit" the moment the count passes it. It never blocks typing, never trims your text, and never adjusts the number for width, device or query. It stops exactly where the modeled rule stops: at a code-point count against a convention, with the judgement about the cut left visible to you. And because there is no server-side counting endpoint at all, everything above runs in your browser — you can confirm in the network tab that typing produces no requests.

Reading a borderline draft

Three drafts for the same imaginary museum show how to read the meter near the line. The first, "Harbour museum opening hours, ticket prices and step-free access, with a map of the three galleries, the sculpture terrace, the shop and the café on the quay.", counts 158 characters: inside the budget with 2 to spare, which the bar shows as almost full. That is a borderline draft, and the right reading is not "safe" but "the complete thought had better come early", because a width-based cut on a line this long can land before the final clause. The second, "Our harbour museum, open every day except Monday, offers guided tours, ticket discounts for families, step-free access throughout, and a quayside café serving local seafood.", counts 173; the display reads "13 over the 160 limit" and the bar changes to its over state. Nothing has gone wrong yet — the draft is over a convention, not a cap — but the end of the line is the part a cut removes, and in this draft the end carries the café. The third, "Harbour museum: open daily except Monday, guided tours, family ticket discounts, step-free access, quayside café with local seafood.", keeps every fact of the second in 132 characters, 28 inside the budget, with the facts ordered so that a cut after any clause still leaves a complete offer standing.

The method follows from the mechanism. Put the complete thought first and make each later clause independently useful; read the remaining count as a margin, not a guarantee; and when the bar is nearly full, look at the snippet Google actually renders for the page rather than at any counter, this one included. Until a consequential description has been verified against the platform itself, a third-party counter is a drafting aid, not a guarantee.

Common misreadings

Treating the budget as a field size. The over state is a drafting signal, not a submission error. The figure is ~160 because that is how the platform's published rules read as of mid-2026, and the page says so rather than rounding it into a rule it is not.
The curly apostrophe. On the SMS counter, a curly apostrophe pasted from a word processor is the classic silent flip: one character outside the GSM-7 alphabet moves a whole message from the 160-septet budget to the 70-unit Unicode one. Here it changes nothing. "Here's what's included in every plan" with straight apostrophes counts 36; "Here’s what’s included in every plan" with curly ones counts 36. One code point is one code point whichever glyph it is — the SMS page runs a different algorithm, not a different opinion about the same count.
Emoji as two. "Grand opening this Saturday" counts 27; "Grand opening this Saturday🎉" counts 28, so the 🎉 added exactly 1. Two is the right answer elsewhere for other reasons: the X counter describes X's weighting of emoji at 2, per its developer documentation as of mid-2026, and the SMS counter prices most emoji at two UTF-16 units once a message is in UCS-2. Neither rule applies to this page.
Reusing one count across platforms. The same draft is a different length on each page of this site because each page models a different rule, with its cap stated as of mid-2026 the way the methodology page states it and updated when the platform changes it — 280 code points on X with its described weighting, 2,200 on Instagram with its ~125-character fold, 100 for a YouTube title, septets or UTF-16 units for SMS. Run each destination against its own page.
Reading "remaining" as "visible". 2 remaining means the draft sits 2 characters inside a convention; it says nothing about where a width-based cut lands. The guide on truncation and folds is the longer version of that sentence.

Frequently asked questions

Is 160 characters a hard limit?

No. The ~160 figure is a drafting convention that reflects the platform's published rules as of mid-2026; the behaviour behind it is a cut made by rendered pixel width, not a cap counted in characters. This page states the figure the way the methodology page does and updates its copy and preset when Google changes it. Treat the meter as a budget and the snippet Google renders as the final authority.

Why can't the checker show where the snippet will be cut?

Because Google's pixel-width snippet cut is described on this page, not modeled. Simulating it would mean guessing at glyph widths, devices and queries from the outside, and the site's methodology draws its line exactly there. The checker models one thing, a code-point count against the 160-character budget, and tells you which way the unmodeled cut can skew it: in either direction, which is why the remaining count is a margin rather than a visible length.

What counts as a character here?

Unicode code points. Letters, digits, spaces, punctuation and line breaks each cost one; an accented é is one, a CJK character is one, and an emoji such as 🎉 is one code point even though it occupies two UTF-16 units. A joined family emoji is several code points and the meter reports the code points: 5 for 👨‍👩‍👧. Platforms disagree on such sequences, so the platform itself is the final authority on a borderline draft.

Does an emoji count as one or two?

One code point on this page: "Grand opening this Saturday" counts 27 and "Grand opening this Saturday🎉" counts 28. Two is the right answer on other pages for other reasons. The X counter describes X's weighting of emoji at 2 as of mid-2026, and the SMS counter prices most emoji at two UTF-16 units once a message is in UCS-2. Neither rule is applied here.

Why does the same draft read a different length on the SMS counter?

Because that page runs a different algorithm, not a different count. SMS budgets follow GSM 03.38, and a curly apostrophe pasted from a word processor flips a message from the 160-septet budget to the 70-unit Unicode one. Here a curly and a straight apostrophe are each one code point: "Here’s what’s included in every plan" and "Here's what's included in every plan" both count 36.

What about title tags?

This site states no figure for HTML title tags. The only search-snippet number stated anywhere on it is the ~160-character description budget, as of mid-2026, and a title cutoff it cannot verify is left unstated rather than guessed. The checker above counts whatever you paste, so a title can be checked against a budget you have confirmed yourself.

What happens when I go over 160?

The display switches from "remaining" to "over the 160 limit" and the bar changes state; nothing is blocked or trimmed. The over-length museum draft in the worked example reads 13 over, and the fix is not to delete its last 13 characters but to reorder it so the complete thought comes first, as the trimmed version does at 132 characters.

Is anything I type sent to a server?

No. There is no server-side counting endpoint: the count, the bar and the word stat are all computed in your browser, and nothing is transmitted, logged or stored. You can confirm it in your browser's network tab while typing.

The 160-character budget is a drafting convention for Google's display-width truncation — actual cutoffs vary by device and query. Nothing you type is transmitted or stored. See the methodology page.