Characters are the wrong unit
The advice to keep a title under sixty characters is a useful approximation and a poor rule. Search results are not rendered in a monospaced font, so a character is not a fixed amount of space.
Compare a title made mostly of narrow letters against one made of wide ones. In a proportional font the second can be half again as wide at the same character count, and the first can carry noticeably more text before it is cut. Capital letters, the letter W, and most punctuation are wide; lowercase i, l and t are narrow. A title full of them behaves nothing like its character count suggests.
What actually decides truncation is width. So the measurement here is a width, taken by asking the browser to measure your text in a font approximating the one search results use at the relevant size, and comparing that against a limit.
Checking a title and description
- Paste your title into the first box, labelled Original text.
- Paste your meta description into the second, labelled Changed text. Either box alone is enough to run.
- Set Simulated device to Desktop Google Search (default) or Mobile Google Search.
- Click SEO Title & Description Pixel Counter.
- Read the report. Each field gets its own labelled section with the character count, the estimated width, the approximate limit, and whether it is likely to be cut.
- When a field is over the limit, the report also shows the text as it would probably appear, ellipsis included.
- Copy to clipboard takes the whole report; Compare another clears both boxes.
The two input labels are a borrowed artefact of the shared two-box layout and do not describe what they hold here. The report labels leave no doubt.
Approximate, and openly so
Every number this tool produces is an estimate, and the report leads with that rather than burying it.
Google publishes no truncation width for either field. It never has. What exists is a body of measurements taken by SEO tools over the years, which broadly agree, and which have had to be revised whenever Google changed its font stack or its layout. Different popular tools still quote slightly different figures today.
Mobile is a rougher approximation again. Far fewer tools model it, the column width varies more across devices, and there is correspondingly less consensus to draw on.
Treating any of this as a specification is a mistake. The right use is comparative: this title is comfortably inside, that one is well over, this rewrite pulled it back under. Optimising to the last ten pixels of an unofficial number is effort spent on a figure that may change next quarter.
How the truncation preview is built
Finding where a string will be cut is a search. The full text is measured first, and if it fits, nothing more happens.
If it does not, characters are removed from the end one at a time, and after each removal the remaining text plus an ellipsis is measured. The first candidate that fits is the answer. Trailing whitespace is stripped from the cut before the ellipsis is appended, which is the difference between a clean ending and one with a visible gap before the dots.
The search walks character by character rather than bisecting. For a field of a few dozen characters the cost is irrelevant, and a linear scan is easier to be confident is correct.
There is one degenerate case: if not even a single character plus the ellipsis fits, the preview falls back to the ellipsis alone rather than to an empty string.
Where this fits in the workflow
Write the tags first, then measure. Meta Tags Generator produces the full set including the social preview tags, and this page is where you check the two that get truncated.
For the same question on social platforms, which count characters rather than pixels and each count differently, Social Media Character Counter is the equivalent. Keyword Density Checker looks at the page body rather than the tags, and Schema Markup Generator builds the structured data that decides what else can appear in a result. The rest is on the dev tools hub.
