Truncation and folds: what the checker cannot see

Every limit checker on this site answers one question exactly: how many Unicode code points are in your text, and how many remain against a platform's published cap. Three of the platforms also do something the checker cannot see. Instagram folds a caption in the feed well before its cap; YouTube cuts a title short at a point that depends on the device; Google ends a search snippet by its rendered width rather than by any character count. This guide describes each of those cuts the way the methodology page does — as behavior that is stated, not simulated — says which direction each one skews the number you see here, and shows, with counts computed by the engine, what the checker reports instead.

Every platform figure below is that platform's published rule as of mid-2026. Caps and folds are product decisions, not standards: when a platform changes one, the page copy and the preset are updated. Until then the numbers are a drafting aid, and the platform's own composer is the final authority on a borderline draft.

Two kinds of limit

A cap is a published figure the engine counts against, and past it the draft is over: Instagram's caption cap is 2,200 characters, and YouTube's title field takes 100. A fold is different. A draft that fits the cap can still be shortened in display — only part of it is shown until a reader acts, or only part of it fits the surface it is shown on. The caption past Instagram's "…more", the tail of a title on a narrow surface, and the end of a search snippet are all folds.

The engine models caps because a cap is arithmetic: count the code points, subtract from the published figure, report the remainder. It does not model folds, because a fold is not arithmetic. Where a fold lands depends on the platform's display behavior, on the device, and in Google's case on the width of the letters themselves — none of which a character count can observe. Simulating one would mean guessing at behavior that cannot be verified from the outside. The rule, set out in modeled versus described and applied across the guides, is that a fold is described on the page and kept out of the engine.

Instagram's ~125-character feed fold

As of mid-2026, Instagram caps a caption at 2,200 characters and folds it in the feed at roughly 125, behind "…more". The cap is modeled: the Instagram caption counter counts code points against 2,200. The fold is described, not modeled — and the tilde in "~125" is the reason. It is an approximate figure for a display behavior, and the checker will not pretend to know the exact character at which a given phone decides to fold.

Take a caption that opens with the sentence "Three things we changed about the bread this season, and the one thing we refused to." and continues: "The flour is now milled the day before baking. The proof runs overnight instead of through the afternoon. The oven sits a little cooler. What stayed is the starter, fed the same way since the shop opened." The engine reports the whole caption at 291 code points, 1,909 short of the cap — a bar that is barely off empty. Counted on its own, the opening sentence is 85 code points, inside the ~125 figure, so the fold lands somewhere in the paragraph that follows it. Now take a caption whose first sentence runs "We spent the whole of the spring rebuilding the oven, relining the floor, resetting the flue, and arguing about whether the door should open to the left or the right, and in the end the answer was neither." That sentence alone is 205 code points. Against the cap it is nothing; against the fold it means the sentence is cut mid-clause for anyone who does not tap "more".

The direction of the skew is one way. The checker compares against 2,200, and ~125 is well below that, so a reassuring meter is not evidence that a caption displays in full. The checker can never read pessimistic about the fold — it has no way to flag one — and it cannot read correct about it either, because it does not look. What it gives you is the exact count of whatever you paste — which is why counting the opening sentence separately is the useful move.

YouTube's device-dependent title truncation

As of mid-2026, YouTube's title field accepts 100 characters, and the YouTube title counter checks against that figure. Where a title is truncated when it is shown depends on the device and the surface showing it, and so the truncation is described, not modeled. There is not even an approximate figure to put a tilde on: a single number would misstate the behavior on every surface but one.

The title "Sharpening a Chisel by Hand: Flattening the Back, Setting the Bevel, and Honing Without a Jig" is 93 code points, 7 inside the field cap. The checker passes it, correctly. Whether the final clause survives on a given surface is a separate question that no count answers. Shorten it to "Sharpening a Chisel by Hand" and the count drops to 27; the shorter title has less to lose at any truncation point, without a promise about any particular one.

The skew runs the same direction as Instagram's. The engine passes anything up to 100, and a visible cut, where it happens, happens below the full length of the title. A pass against the cap is a necessary condition for the title displaying whole, not a sufficient one.

Google's pixel-width snippet cut

Google ends a search snippet by its rendered width in pixels, not by a character count, and that is the whole reason the meta description checker frames ~160 as a drafting budget rather than a cap. As of mid-2026 the budget stands at ~160. It is a convention for drafting against a width cut, and the cut itself is described, not modeled, because the engine does not render text and has no typeface to measure.

Two strings make the gap visible. "MMMMMMMMMMMMMMMMMMMM" and "iiiiiiiiiiiiiiiiiiii" are each 20 code points — the checker reports them as identical, and against the 160 budget each has 140 remaining. In any proportional typeface the first is visibly wider than the second. A cut made by width treats them differently; a count cannot tell them apart. A realistic description, "Hand tools for timber framing: chisels, slicks, and framing squares, with sharpening notes and a guide to choosing a first set.", comes to 127 code points with 33 to spare, which says it is inside the drafting budget and nothing more: whether its last clause renders before the cut depends on the rendered width of those letters on that device, which the engine never measures.

Unlike the two folds above, the skew here has no fixed direction. A description inside the budget can still be cut in display, and because the cut is by width rather than by count, the budget is a proxy whose error has no fixed sign. The count is serviceable for ordinary prose as a drafting budget, but it is a proxy all the same, which is why the page shows a budget and declines to show a verdict.

What the checker shows instead

In every case the checker shows one thing: the code-point count of what you pasted, and the remainder against the platform's published cap. Code points are the convention most platforms document for their caps, and the engine counts them strictly — "Café night 🎉" is 12 code points, with é as one and 🎉 as one. Nothing in that count is approximate, device-dependent, or width-dependent — which is why it is the part that runs in the engine.

Reading a borderline draft

Borderline, for a fold, means near the fold rather than near the cap, and the reading changes accordingly.

• Count the part that must survive on its own. Paste only the opening sentence of a caption, or only the title, and read its code-point count. The count is exact; the comparison against ~125, or against a device-dependent cut, is yours to make, with the tilde kept in mind.
• Read a green bar as a cap result, not a display result. "1,909 remaining" says the caption above will be accepted. It says nothing about how much of it the feed shows.
• Put what must be seen where a fold cannot reach it. The only position on a folded surface that is guaranteed to display is before the fold, so the sentence that cannot be lost belongs first, and its count is the one to watch.
• Make the final call in the composer. Instagram's app, YouTube's upload form, and a search result for your own page are the only places a fold is real. Paste the finished draft there and look. Folds are product decisions a platform can change, so that check belongs at send time, not only at drafting time.

The one cliff the engine does model

The site refuses to simulate folds because they are display decisions; it does simulate SMS segmentation, down to the character, because GSM 03.38 is a stable standard. The standing example is the curly apostrophe. "Your table is booked for tonight at the usual time. Reply if you can't make it and we'll release it." is 100 code points; replace its straight apostrophes with the curly ones a word processor substitutes and it is still 100 code points — identical to any limit checker. The SMS engine sees the difference. With straight apostrophes the message is GSM-7: 100 septets, 1 segment, 60 spare of 160. With curly ones, the first character outside the GSM-7 alphabet flips the whole message to UCS-2, counted in UTF-16 units — 100 of them at 67 per segment — and the same text is now 2 segments. That cliff is modeled because the standard says exactly where it is. A fold is not, because nobody outside the platform can say the same.

Frequently asked questions

Folds and truncation are described on this page and on each checker, never simulated; counting is in Unicode code points against each platform's published cap as of mid-2026. Nothing you type is transmitted or stored. See the methodology page.