Platform limits as of mid-2026

This page lists every character limit CharLimit.net checks, states each one as of mid-2026, and explains what the number means before you lean on it. Platform caps are product decisions, not standards: a platform can raise, lower or re-weight its limit whenever it chooses, and the only honest way to publish one is with a date attached and a promise to update it. When a platform changes a limit, the page copy and the preset are updated — and until you have verified a consequential send against the platform itself, each figure is a drafting aid rather than a guarantee.

The limits this site checks

Five caps, one engine. Each row names the figure as of mid-2026, the unit it is counted in, the page that checks it alongside the platform's fine print, and the preset chip on the homepage checker that applies the same number to any text.

Two notes the table cannot carry. SMS is not a cap but an encoding rule with a budget attached, and only the SMS counter runs that arithmetic; the homepage's SMS preset is a plain code-point check against 160. And the tilde on the meta description figure is deliberate: Google cuts snippets by pixel width, not character count, so ~160 is a drafting budget rather than a limit anyone enforces.

Why every number carries a date

SMS arithmetic follows GSM 03.38, a stable specification, which is why the SMS figures are stated without hedging. The other four are different in kind. X's limit was 140 until 2017, when it became 280 for standard posts; paying subscribers now post far longer, and that longer length is not stated here because it is a tier, not the standard cap. Instagram's 2,200, YouTube's 100 and Google's ~160 are likewise whatever those products currently publish or display, and any of them could change between the day this page is built and the day you read it. "As of mid-2026" is therefore part of the figure, not a disclaimer. When a platform changes a limit, the affected page and its preset are updated; the methodology page carries the same figures so the two can be checked against each other.

What is counted

For X, Instagram, YouTube and meta descriptions the checker counts Unicode code points. In practice: é is one character, a CJK character is one, and 🎉 is one code point — the engine counts it as 1 toward a limit — even though it occupies two UTF-16 units in JavaScript's internal representation. The known wrinkle is multi-part emoji. A family emoji such as 👨‍👩‍👧 is a single visible glyph built from several code points joined by invisible joiners; the engine reports 5 for it, and platforms themselves disagree on how to count such sequences.

SMS counts something else entirely. The engine walks the message against the GSM-7 alphabet: basic-set characters cost one septet, the extended set (€ [ ] { } ~ ^ \ |) costs two, and the first character outside both sets switches the whole message to UCS-2, where length is counted in UTF-16 code units and most emoji cost two — that same 🎉 is 2 units in an SMS. A GSM-7 message fits 160 septets in a single segment or 153 per segment once concatenation headers are needed; UCS-2 fits 70, or 67 concatenated.

Why the platform's own count can differ

Some platform behaviour runs in the engine and some is only described; the line is drawn where simulation would mean guessing at server-side behaviour that cannot be verified from the outside. Modeled: code-point counts against each published cap, and the full GSM-7/UCS-2 segmentation. Described, not modeled, are four quirks:

• X's weighted counting. Per X's developer documentation as of mid-2026, every URL is counted as a fixed 23 and emoji and CJK characters are weighted 2. The checker counts a pasted URL at its real length and an emoji at 1; the direction of the skew is stated, the weighted total is not computed.
• Instagram's ~125-character feed fold. The cap is 2,200; the feed shows roughly the first 125 characters before folding the rest. The checker tracks the cap and does not simulate where the fold falls.
• YouTube's device-dependent title truncation. The field accepts 100; where a given surface truncates the title varies by device, and no single number would be honest.
• Google's pixel-width snippet cut. Width, not characters, decides the cut, so the 160 preset is a budget and the page says so.

Each cap, checked by the engine

The figures below are computed by the same functions the live checkers call, on the sample text shown, so the prose cannot drift from the engine.

X: 280

The post "Launch day. The new checker is live, the old address redirects, and the changelog explains what moved." is 102 code points, leaving 178 of 280. Add a link and an emoji — "Full notes here: https://example.com/notes/launch-day-changelog 🎉" — and the checker reads 65, of which the URL alone is 46 code points. X would count that URL as 23 and the emoji as 2, so its figure for this post is lower than the checker's; a post written in CJK characters would skew the other way. The X/Twitter counter explains both skews beside its remaining count.

Instagram: 2,200

A two-paragraph caption — "New batch, same recipe. Sourdough proofed overnight and baked at dawn. Pick-up from the counter until noon. #sourdough #bakery", with a blank line between its paragraphs — counts 127 code points, line breaks included, leaving 2,073 of 2,200. That is already past the ~125-character feed fold, which is the practical point about this cap: most captions meet the fold long before the wall, and the fold is described, not simulated. The Instagram caption counter tracks the wall and leaves the fold judgment to you.

SMS: 160 or 70

"You're invited to Friday's launch at 6 pm. Reply YES to confirm.", with straight apostrophes, is GSM-7: 64 septets, 1 segment of 160, 96 to spare. Paste the same sentence from a word processor that has curled both apostrophes and the engine reports UCS-2: still 64 units, still 1 segment — but the segment now holds 70, so only 6 remain. Nothing visible changed. This is the classic silent flip, and the reason the SMS counter prints the detected encoding rather than a bare count.

Longer messages show the concatenation budgets. The reminder "Reminder: your appointment is tomorrow at 9:30 am at the High Street clinic. Please arrive ten minutes early and bring your referral letter. Reply C to cancel or R to reschedule." is GSM-7 at 178 septets: 2 segments of 153, with 128 septets left across the pair. Reword its opening to "Reminder: you’re booked for tomorrow…" with a curly apostrophe and the whole message is UCS-2 at 176 units — 3 segments of 67, 25 units left. Extended characters cost in the other direction: "Tickets €12 at the door [cash only]" is 35 characters but 38 septets, because €, [ and ] take two each. National-language shift tables and carrier-side transcoding are not modeled, and carriers can and do vary.

YouTube title: 100

"Sourdough for beginners: a full overnight proof, start to finish" is 64 code points, 36 under the 100 the field accepts. "The complete guide to overnight sourdough proofing for beginners, with every tool, timing and mistake explained" is 111 — 11 over — and the YouTube title counter flags it before the upload form does. Where a given surface truncates a title that does fit is device-dependent — described, not simulated.

Meta description: ~160

"Check any draft against the X, Instagram, SMS, YouTube title and meta description limits as of mid-2026, live in your browser." is 126 code points, 34 inside the 160 budget. Because Google cuts by pixel width, a description inside the budget can still be cut; the meta description checker tracks the budget and says plainly that it is a convention.

What the site refuses to guess

The table is short on purpose. There are no rows for platforms the site does not check, no paid-tier lengths, no bio, name, hashtag or direct-message caps, and no pixel widths for search snippets. Each omission is the same decision: a figure that cannot be stated with the methodology's framing — as of mid-2026, from the platform's published rules, updated when it changes — is not stated at all, because an inferred number in a limit checker is worse than none. For anything missing, the platform's own composer is the right instrument — and the final authority on a borderline draft in every case.

How to read a borderline draft

The guidance below is for the last stretch of a draft, where the unit of counting and the described quirks start to matter:

• Check the unit before the number. On the SMS page, read the encoding line first; a count that looks comfortable against 160 is over budget if the message has quietly become UCS-2 and the budget is 70.
• Know which way each described quirk pushes. A link-heavy X draft that reads over here may fit on X; an emoji-heavy or CJK draft that reads fine here may not. On Instagram and YouTube, fitting the cap says nothing about where the fold or the truncation falls.
• Count sequences, not glyphs. A joined emoji that looks like one character is several code points here and may be weighed differently elsewhere; near a limit, that gap is the whole margin.
• Finish in the composer. For a consequential send, paste the final text into the platform itself. The checkers here exist to make that last check uneventful, not to replace it.

Related guides

The guides index expands on this table: counting characters in code points, SMS segments and GSM-7, X's weighted counting, truncation and folds, and the site's modeled-versus-described doctrine.

Frequently asked questions

The caps in this guide reflect each platform's published rules as of mid-2026 and are updated when a platform changes one; every count in the worked examples is computed by the site's engine on the sample text shown. Nothing you type is transmitted or stored. See the methodology page.