Why the character limits are approximate
Search results do not truncate at a character count. They truncate when the rendered title reaches the width of the container, which means a title in capitals with wide letters is cut several characters earlier than the same count in narrow ones, and the container itself differs between desktop and mobile. The commonly quoted 60 characters is a working figure derived from roughly 580 to 600 pixels of a 20px system font for ordinary Latin sentence case. The pixel estimate on this page uses per-character advance widths for that same rough font, and its job is to rank your candidates against each other rather than to predict a specific engine.
The other two destinations behave differently again. A social card gives two or three lines, so under 60 characters leaves visible empty space and over 90 gets clipped. Email subject lines are the harshest: a desktop client might show 60 characters and a phone in portrait closer to 35, which is why 45 is a defensive number rather than a limit. If a title is close to any of these, look at it in the real destination before publishing.
The front of the title carries the load
A headline is read in a list next to other headlines, quickly, and often already cut. That makes position more important than total length. Put the subject, the searchable phrase and the form of the piece — comparison, guide, review — at the front, and push the qualifiers, dates and conditions behind them. "Concrete slab thickness: 4, 5 or 6 inches and how to decide" survives a cut at 40 characters with its meaning intact. "A complete and thorough guide to choosing the correct concrete slab thickness" does not, because the first forty characters contain no information about the subject at all.
The default front window here is 30 characters. Drop it to 20 if most of your traffic is mobile, where lists are narrower and the eye moves faster.
What the inflated-language check is really testing
Shocking, ultimate, secret, you-won't-believe and a word in all capitals are flagged, and not on grounds of taste. They are a signal that the title is making a promise larger than the page. A reader pulled in by an inflated headline leaves as soon as the mismatch is obvious, that behaviour is measured, and repeated across a site it works against the pages that do deliver.
The test to apply is concrete: is every claim in the title present in the body? If the title says seven, count seven in the draft. If it says "the mistake that ruins a slab", the draft must contain that mistake and what it ruins. Where the answer is no, the fix is usually the body rather than the title — either write the missing part, or lower the title to match what is actually there.
Working with several candidates, and what this cannot see
Good headlines are rarely first drafts. Write the same idea three or four ways, paste them together and the differences become visible in a way that staring at one version never achieves: which words earn their place, where the subject should sit, how much qualification to keep. Treat the pass count as a tiebreak and nothing more — a title passing five checks that says exactly what the page is beats a bland one passing six every time.
What no structural check can see is whether the title matches the piece, whether it is distinguishable from the near-identical pages already ranking for the same phrase, and whether a reader who has not read the body would guess the right thing from it. Only the last of those has a reliable test, and it is not automatable: show the title alone to someone who has not read the draft and ask them what the page is about. Note also that character counts here are JavaScript string lengths, so an emoji or a flag counts as two or more, and titles in non-Latin scripts are counted per character while the pixel estimate treats them as uniformly wide — a crude approximation that is honest about being one.
Questions people ask
Does it write titles for me?
No. It checks candidates you wrote. A title is a compression of the piece, and only the person who wrote the piece knows what survives the compression — generated headlines are reliably a little bit wrong about their own content in a way that is hard to notice until a reader points it out. The workflow this is built for is: pull three or four candidate framings out of your own draft, paste them together, and compare.
Should every title contain the keyword?
It should if the page is meant to be found by that search and the phrase fits naturally. The check here is about position rather than presence: a keyword sitting at character 70 is invisible after truncation and does nothing for a reader scanning a list. What the tool cannot tell you is whether the phrase is the one people actually type, which is a research question, not a formatting one.
Are brackets and pipes bad?
One or two are fine and often useful — "(2026 update)" packs a qualifier tightly. The flag fires at three or more, where a list of titles starts to look like punctuation soup and the eye slides off. Some symbols also render inconsistently in previews and email clients, and a few get stripped entirely, so anything exotic is worth checking in the real destination rather than trusting here.
Why does the pixel width look wrong for my title?
Because it is an estimate built from a per-character width table for one generic 20px sans-serif, not a measurement of the font your title will actually be rendered in. It is reliable for saying candidate A is wider than candidate B and unreliable as an absolute number. Non-Latin characters are all counted at a single wide value, which is roughly right for CJK and roughly wrong for everything else.