The 60-character title and 160-character description values shown inside a SERP snippet preview are deterministic desktop editing policies of that tool, not official Google truncation guarantees. According to Google's own Search Central documentation, title links are generated automatically from several possible signals—including the title element, visible headings, prominent on-page text, anchor text, and other sources—and snippets are primarily derived from page content, with the meta description used only when it better describes the page. The visible text can shift with the query, language, and device width, and Google does not publish one universal cutoff that applies to every result. A preview tool therefore cannot replicate Google's rendering rule by counting to a fixed number. Instead, the Serp Snippet Preview applies two disclosed preview policies: 60 and 160 code points for the desktop simulation, and 55 and 120 code points for the mobile simulation, replacing the final visible code point with one ellipsis when it shortens. Understanding that gap between a disclosed preview policy and Google's actual generation logic is the only honest way to use the number you see.
Where the 60 and 160 Numbers Come From
The two numbers come straight from the Serp Snippet Preview implementation as disclosed desktop preview policies. They are stated values, not measurements of Google's behavior. When the desktop policy is active, the tool counts Unicode code points of the proposed title and meta description, then shortens at 60 and 160 respectively by replacing the final visible code point with one ellipsis when the text runs past the cap. Characters are counted as code points rather than JavaScript UTF-16 code units, which means an emoji counts as one editor character rather than two surrogate halves. That detail matters because it is the rule the tool applies to the text you paste, not a rule about what Google will do.
Because the numbers are product policies, the result is fully repeatable on your own machine. Two previews of the same input produce the same rendered snippet, the same code-point counts, and the same shortening decision. That reproducibility is precisely why the tool can advertise a fixed preview size while making no claim about Google. Google has stated on its Search Central pages that title links are generated automatically from several signals and that snippets reflect page content first, so no preview tool can guarantee the exact characters Google will display. The 60/160 pair is therefore a writing checkpoint—useful for catching an obviously unwieldy draft—not a forecast.
Why Google Does Not Publish a Single Character Limit
Google does not publish one guaranteed character cutoff for either field, and its title-link documentation explains why: title links are an attempt to describe the page from a blend of the title element, visible headings, prominent on-page text, anchor text, and other signals. The snippets documentation makes the same point about description text. Snippets are mostly pulled from page content, and the meta description is used only when it better summarizes the page. Because the visible text comes from a mix of sources, because the available width changes with the device, and because Google can rewrite what it shows to fit the query, a fixed character cap on Google's side is not a stable target.
The practical consequence is that two pages with the same source title length can show different rendered results in Google, even on identical devices, depending on the query and on Google's processing. The Serp Snippet Preview cannot reproduce that variability because its only inputs are the three text fields you paste. It has no access to the page itself, no signal mix from headings and body copy, and no live rendering pipeline. The 60 and 160 numbers must therefore be read as the tool's repeatable desktop policy—not as a translation of Google's algorithm.
Desktop Policy Versus Mobile Policy in the Tool
The preview exposes two device policies so you can compare a tighter draft against a more generous one before you publish. The numbers are deliberately disclosed because they are simply the code-point caps the tool applies during shortening, nothing more.
| Field | Desktop policy (code points) | Mobile policy (code points) | What happens when the text exceeds the cap |
|---|---|---|---|
| Title | 60 | 55 | Final visible code point is replaced with one ellipsis inside the cap |
| Meta description | 160 | 120 | Final visible code point is replaced with one ellipsis inside the cap |
Notice that the cap is applied to visible code points, not to a pixel width, and that only one ellipsis is inserted when shortening occurs. Internal whitespace and punctuation are preserved, and outer whitespace is trimmed before counting. If you switch from desktop to mobile, a title that fit comfortably under 60 may now shrink because the tighter 55 cap takes over. Switching back simply returns the desktop view. Because everything happens in the browser, you can flip policies as often as needed without sending the draft anywhere.
Build the Preview With These Limits in Mind
Treat the workflow as a three-step writing checkpoint plus one verification step. The tool never reaches the network, so each step is local and reversible.
- Open the Serp Snippet Preview and paste your proposed page title, meta description, and complete HTTP or HTTPS page URL into the three input fields.
- Choose the disclosed desktop or mobile editing policy that matches the device you are targeting, then build the deterministic preview.
- Read the combined result together with the code-point counts beneath it; the source counts show what you typed, while the policy labels show whether the tool shortened either field.
- Revise the page source if the simulation looks awkward, repetition is obvious, or one of the two fields crossed the active cap; switch device policies to compare a tighter draft.
- Verify the deployed HTML separately once the title element and meta description are in place, because the tool never fetches or inspects the live page.
The shortest useful workflow is to draft both fields once, paste all three values, and read the combined result before deciding whether to shorten. A single pass often reveals repetition that two separate form fields hide. If both fields land under the active caps, the tool simply shows the inputs unchanged and reports no shortening. If either field crosses the cap, one ellipsis appears inside that cap. Either way, the result is a deterministic visual draft that you can compare against your editorial judgment rather than against Google's algorithm.
Reading the Combined Result, Not Just Two Counts
The single biggest reader trap with snippet editors is treating the title count and the description count as two independent boxes. The visual preview shows them stacked exactly as they would appear in a search result, so repetition that looks harmless in separate fields often becomes obvious in the combined view. A useful title identifies the page precisely, avoids boilerplate repetition, and matches the visible main heading. A useful description summarizes that specific page in natural language rather than stacking keywords. Reading the simulation as one block is how those issues become visible without leaving the editor.
The tool's input policies also shape what reaches the preview. Source titles are limited to 200 characters and descriptions to 500 characters inside the editor, which keeps the widget responsive and prevents pasted essays from locking the browser. Those are editor maxima, not visible-rendering caps; the smaller device policy still decides what shows in the preview. Trimming outer whitespace before counting keeps stray spaces from inflating the count. If a character feels off after a switch from desktop to mobile, the cause is the tighter policy, not the source text changing.
Practical Limits Inside the Editor
Several disclosed boundaries shape what the tool can and cannot accept. The URL field uses browser-standard URL parsing to canonicalize the host, remove the default port, and percent-encode characters when required. The display hides the scheme for compactness while retaining the normalized full URL internally. A non-default port stays visible because it changes the address, and query parameters stay visible because they may identify the page. Credentials, fragments, raw whitespace, malformed percent escapes, backslashes, relative paths, and non-web schemes are rejected so the polished preview never disguises a malformed address.
Nothing about the preview reaches the network. The tool does not fetch the page, read the title element, inspect a canonical tag, decode structured data, or check indexing status. Unpublished titles and campaign wording stay on the device because the widget runs entirely in the browser. That is also why the result cannot promise a click-through rate, a specific live appearance, or any change to indexing. Treat the preview as a writing checkpoint, implement the title and meta description in the page source, keep the visible body content consistent with them, and verify the deployed HTML once the page is live. Search engines must recrawl and reprocess the page before changes appear, and they may still choose different text. For a focused look at what each editor check actually guards against, the pre-publish privacy walkthrough lays out the same boundaries in checkpoint terms.
What "Official" Really Means Here
Calling the 60 and 160 numbers "official" requires a distinction worth making explicit. Official, in Google's terminology, refers to behavior Google documents about its own systems: that title links and snippets are generated automatically, that the visible text can vary by query and device, and that no single character count is a hard guarantee. The 60 and 160 numbers in the Serp Snippet Preview are official in a different sense: they are the published, disclosed preview policies of that tool. The two uses of "official" do not overlap. Reading the numbers as if they came from Google's rendering pipeline will produce drafts that satisfy a simulation while missing the page-level signals Google actually consults. Reading the numbers as the tool's repeatable desktop policy keeps them useful without overclaiming.
For a deeper look, see Email Obfuscator Safe: Honest Limits and a Safer Setup.