Why 60 characters was always a rough guess for meta titles
The 60-character rule is a proxy that lands near the right answer for average English text. It fails on anything that is not average.
Take 2 place names of exactly 10 characters each. "Lillington" renders at roughly 85px. "Wollongong" renders at roughly 111px. Same character count, 26px apart, which is 4 or 5 characters of headroom you either have or you do not. Scale that up and a title heavy in narrow glyphs can carry 68 characters inside the budget while one full of m, w, M and W truncates around 52.
The width table the tool works from, approximately, at the size Google renders desktop titles:
- Narrow glyphs (i, l, j, t, f, r, I, parentheses, punctuation): about 6px
- Wide glyphs (m, w, M, W): about 16px
- Most lowercase letters: about 10 to 11px
- Most capitals: about 13px
- Digits: about 11px
- A space: about 5 to 6px
Add those up and you get a number that predicts truncation far better than a character count does.
What the pixel estimate is and is not
Each option comes back with an estimated pixel width, a character count for comparison, and a truncation flag. The tool draws each width as a bar against the 580px line, colored green when it fits and red when it does not, so overflow is visible rather than something you compute.
2 things worth knowing. The flag is derived from the width actually displayed, so the badge and the bar can never disagree. And when a returned width falls outside a sane range, the interface discards it and measures the string locally instead, so you never see a blank or obviously wrong bar.
It is still an estimate, not a screenshot of your result. Rendering shifts with the device and the font stack. Treat 580px as a line to stay behind rather than a number to hit.
The 5 fields and what each one changes in your title output
Page topic (required) is what the page is about, in plain words: "project management software for agencies."
Primary keyword (required) is the query the tag has to match. Most options front-load it, and every option reports whether the keyword sits at the front, in the middle, or at the end.
Page type picks between homepage, blog post, product, category, landing, and local. This changes the writing rules, not just the wording.
Brand name is appended as a suffix when the toggle is on.
Append brand to each tag is that toggle. Turn it off for long keywords. The suffix costs real budget: " | Foldstack" is about 100px, roughly a sixth of your space spent on a word most searchers already know.
Before the first run, the tool asks you to pass a quick human check. It calls a language model, and the check keeps automated traffic off the endpoint; one pass covers a window of about 30 minutes, so a batch of runs only asks once.
Rules that change with the page type
- Homepage: names what the business does, not just what it is called. Brand alone spends the whole budget on a query only people who already know you will type.
- Blog post: reads informational, the question or the how or the number. Sales language on an informational query is a mismatch that shows up as a bounce.
- Product: leads with the product name, its category, and one differentiator a buyer actually filters on.
- Category: names the collection plus a count, a qualifier, or a price or spec filter shoppers use.
- Landing: makes the offer and the outcome explicit. It is the promise the ad or the link already paid for.
- Local: pairs the service with the city or region, because on a local query the location is half of what was typed.
Modifiers vary across the 8 options, so no 2 share a pattern: year, number, benefit, qualifier, location, comparison, and question each appear at most once.
The short option and who it is for
One of the eight comes back deliberately under 400px. That is not a mistake or a weak draft.
Mobile results render narrower than desktop, and a tag that fits on a laptop can lose its tail on a phone. If most of your traffic is mobile, or the keyword absolutely has to survive the cut, that option is the safe pick.
At most one of the eight may run past 580px, and only when the extra words earn it. It comes back flagged as truncating, with the overflow in pixels on the card, so you choose it knowingly rather than ship it by accident.
A worked example of a generated meta title
Page topic: project management software for agencies. Primary keyword: agency project management software. Page type: product. Brand: Foldstack, toggle on.
One of the eight came back as "Agency Project Management Software | Foldstack" at 45 characters and roughly 440px, leaving 140px unused. The character count says the tag is a reasonable length. The pixel count says there is room for a differentiator, a price qualifier, or a client-count number before anything gets cut. That gap is the whole reason the tool works in pixels.
Results sort by whether the tag survives the SERP: fits first, then keyword position weighted toward front-loading, then how much of the width it uses.
What the tool cannot do for you
It cannot stop Google rewriting your tag. Search engines replace titles in a meaningful share of results, often pulling your H1 instead. A good tag makes that less likely; it does not prevent it.
It has no access to your rankings, your SERP, or your competitors' tags, so it does not know that four of the top 5 results already lead with a year stamp. It also does not check for duplicates across your site, which is a common and quietly expensive problem.
Every option is downloadable as CSV with the pixel width, character count, truncation flag, and keyword position per row, which is the fastest way to hand a batch to whoever owns the template. If you would rather the whole page came out written and tagged, BlazeHive automates SEO content end to end.