A SERP snippet preview handles large text by enforcing two separate sets of rules: editor input caps of 200 characters for titles and 500 for descriptions, and smaller disclosed preview policies of 60/160 code points on desktop and 55/120 on mobile that replace the final visible code point with a single ellipsis when text is shortened. Character counts use Unicode code points rather than JavaScript UTF-16 code units, so a long sentence containing emoji or accented characters still behaves predictably in the counter. The preview is deterministic — the same three inputs always produce the same visual draft — and it never fetches the page, reads HTML, or submits the URL anywhere. All processing stays on the device you typed on, so unpublished titles and campaign wording remain local. The editor trims whitespace at the outer edges of each field but leaves internal spacing and punctuation alone, which matters when comparing two drafts of the same sentence for length. This separation lets writers tighten a bulky title or description before it reaches a content management system, instead of discovering an awkward cut on a live search results page.
What "large text" means inside a SERP snippet preview
In a search results page, the visible snippet is only as wide as the device that renders it. A title that reads comfortably on a wide desktop monitor can wrap onto two lines or be cut on a narrow phone screen, and a description that fits a desktop column can spill past the visible area on mobile. The whole point of a SERP Snippet Preview for large text is to simulate that wrapping and cutting inside the browser, before the page is published, so a writer can see where a sentence will visibly break.
"Large text" in this context is anything beyond what the disclosed preview policies will keep verbatim. The desktop policy keeps 60 code points for titles and 160 for descriptions; the mobile policy keeps 55 and 120. A title of 78 code points is "large" relative to the desktop policy, and the preview will visibly shorten it. A description of 198 code points is large relative to both policies, and the desktop draft will already show truncation. Large text is not automatically a problem — it simply triggers the shortening path defined by the chosen device policy, and the counter still reports the original length so the writer can see both values.
Editor input caps versus preview truncation policies
The tool applies two different sets of limits, and confusing them is the most common reason a large-text workflow produces confusing results. The first set is the editor caps: titles are limited to 200 code points and descriptions to 500, enforced so the browser editor stays responsive. The second set is the preview policies described above. Pasting text past the editor caps is rejected before any preview runs; pasting text inside the editor caps but past a preview policy triggers shortening inside the preview only.
| Field | Editor input cap | Desktop preview policy | Mobile preview policy |
|---|---|---|---|
| Title | 200 code points | 60 code points, one ellipsis replaces the final visible code point when shortened | 55 code points, one ellipsis replaces the final visible code point when shortened |
| Description | 500 code points | 160 code points, one ellipsis replaces the final visible code point when shortened | 120 code points, one ellipsis replaces the final visible code point when shortened |
These numbers are deterministic editing rules used by this widget. According to Google's title links documentation, Google generates title links automatically from several signals, including the title element, visible headings, prominent page text, anchor text, and other sources, and the final text varies with query, language, and device width. The tool's policies are therefore a repeatable editing aid, not a reproduction of Google's algorithm.
How to preview large title and description text
Running a large draft through the preview is a small, repeatable sequence. The steps below follow the verified operating flow for the tool and assume the draft is genuinely long enough to trigger shortening.
- Open the Serp Snippet Preview and enter the proposed page title, the meta description, and the complete HTTP or HTTPS URL of the page the draft is for. Keep the title under 200 code points and the description under 500 so the editor accepts them.
- Choose the desktop or mobile editing policy before building the preview. Picking the device first matters because switching later changes which line gets cut and where the ellipsis falls.
- Build the preview and read the source character counts the tool reports beside the result, not the visible line alone. If the title is 78 code points on desktop, the counter shows 78 and the visible preview shows the last visible code point plus one ellipsis once the 60 code point policy is applied.
- Compare the desktop and mobile drafts of the same text side by side, noting where each one shortens. A title that reads cleanly under 60 code points on desktop can still wrap or shorten at 55 on mobile.
- Revise the source text if a shortening point falls mid-word or strips a meaningful qualifier, then rebuild the preview with the same device policy to confirm the change.
- After the editor pass, place the final title and meta description into the page source, keep the visible on-page heading consistent with them, and verify the deployed HTML separately.
Worked example for a long title: paste a title of 78 code points, choose desktop, build the preview. The source counter reads 78; the desktop policy of 60 code points shortens the visible draft to 59 visible code points followed by one ellipsis, because the ellipsis replaces the 60th visible code point. Switching to mobile produces a tighter cutoff at 55 code points, again with one ellipsis, so the same draft tells two different shortening stories depending on the chosen device.
What truncation looks like in the simulated result
When a field is shortened, the preview replaces only the final visible code point with one ellipsis and preserves everything before it. Internal spacing and punctuation are unchanged, so a long sentence with a list inside it still reads naturally up to the cut. The URL is treated separately: the preview hides the http or https scheme for compact display, keeps the normalized host and a non-root path, and leaves a non-default port or any query parameters visible because they identify the proposed page.
URL fields that fail the parser are not previewed at all. Credentials, fragments, raw whitespace, malformed percent escapes, backslashes, relative paths, and non-web schemes are rejected, which is useful when a long URL also contains unusual characters that should not be quietly accepted. A non-default port stays visible because it changes the address; query parameters stay visible because they may identify the proposed page; the scheme is hidden because the eye reads hosts and paths more easily without it.
For more on the exact rule set, the SERP Snippet Preview Cheat Sheet lays out the editor caps, the device policies, and the URL parser in one place.
Tightening an oversized draft before publishing
Large drafts usually fail for one of two reasons: a bulky title that tries to repeat the brand name and the keyword and the value proposition all at once, or a description that summarizes the page in marketing language instead of plain language. A useful title identifies the page precisely, avoids boilerplate repetition, and matches the visible main heading on the page itself. A useful description summarizes the specific value of that page in natural prose rather than stacking keywords.
Reading the simulated title and description together catches repetition that looks harmless in separate form fields. A title that already says "Free Online Tool" and a description that begins "Use our free online tool" together read as filler once the preview stacks them. Cutting one of the two phrases usually pulls both lines inside the device policy without losing meaning, and the preview will confirm it. Switching the device policy to mobile is a fast way to expose any draft that only fits on a wide screen.
Verifying the deployed page after the editor pass
The preview is a writing checkpoint, not a deployment step. After the final title and meta description are placed into the page source, the visible on-page content should remain consistent with them — a description promising a calculator should land on a page with a calculator. The deployed HTML is then verified in a separate pass, because the preview never fetches the URL, reads the title element, inspects canonical tags, checks structured data, or queries indexing status.
Search engines must recrawl and reprocess a page before changes can appear, and they may still choose different text. Per Google's snippets documentation, snippets are primarily generated from page content and may use a meta description when it better describes the page, which means the final search result can still differ from any local simulation. The preview is a useful draft-stage check for large text; the live SERP is the only authoritative test of how a tightened title or description will actually render.
If you're weighing options, Extract URLs From a Sitemap in Bulk: Limits and Counts covers this in detail.