X's weighted counting, explained
The X/Twitter checker on this site counts Unicode code points against a 280-character cap. X itself counts differently: it replaces some characters with a fixed charge and weights others double. This guide states X's rules as of mid-2026, explains exactly what the checker does with them — which is to describe them, not simulate them — and works out which direction the difference runs, so a borderline draft can be read correctly rather than hopefully. Where it says "X weights" or "X bills," it is repeating X's own developer documentation as of mid-2026; where it says "the checker counts," it is describing the engine that runs in your browser.
The limit itself: 280, as of mid-2026
For standard posts, X's limit is 280 characters as of mid-2026. It was 140 until 2017, when it doubled. Paying subscribers can now post far longer; this site deliberately states no figure for paid tiers, because that ceiling is a product decision X can revise at any time. The checker's preset is 280, and when X changes the standard limit, the preset and the page copy are updated together. The platform-limits guide collects every cap on this site under the same framing, and the guides index lists the rest.
What X weighs, and what it does not
X's developer documentation describes a weighted count rather than a plain character count. As of mid-2026, three rules decide what a draft costs:
- Face value. Letters, digits, punctuation, spaces, line breaks, @mentions and #hashtags each count as what they are.
- URLs: fixed at 23. Every URL is billed at 23 characters regardless of its real length. A long link does not cost its length; a short one does not cost less than 23.
- Emoji and CJK: weighted 2. An emoji counts 2, and so does a CJK character — Chinese, Japanese and Korean.
What the checker counts instead — and why X's weighting is described, not modeled
The checker computes one thing: the number of Unicode code points in your draft, compared against 280. That is the same unit every limit check on this site uses, and the methodology page explains why: it is the convention most platforms document, a CJK character is one, and an emoji like 🎉 is one code point even though it occupies two UTF-16 units inside JavaScript. The checker does not shorten URLs, does not weight emoji, and does not weight CJK.
The methodology page draws this line in the same place for every platform quirk on the site, and the modeled-versus-described guide sets out the doctrine in full: a rule is modeled when the engine can compute it without guessing, and described when simulating it would mean guessing at server-side behavior. X's weighting is the second kind. A simulation would have to decide whether a bare domain with no scheme is a URL, whether a trailing period belongs to the link, whether a family emoji built from several joined code points is charged once or per part, and where the CJK ranges begin and end. Each is a server-side judgment this site cannot verify, and a simulation that got any of them wrong would hand you a confident, precise, wrong number. An exact code-point count with a stated direction of error is the more useful instrument.
Which direction the checker skews
Because the rules are known even though their edges are not, the direction of the difference follows from them without any guessing:
- Emoji: the checker reads low. Each single-code-point emoji is one here and weighted 2 at X. Every such emoji in a draft is therefore at least one unit of headroom that the meter shows and X does not grant. This is the dangerous direction — a draft the checker calls inside the limit can be outside it at X.
- CJK: the checker reads low, by the same mechanism. A draft written mostly in Chinese, Japanese or Korean runs out of room at X well before the checker's meter says so.
- URLs: the checker usually reads high. A pasted link is counted at its as-written length here and billed at a fixed 23 at X. Any URL longer than 23 characters as written makes the checker pessimistic, the safe direction. A URL shorter than 23 characters as written would run the other way, but a complete link that short is unusual.
- Plain text: no skew is expected. Letters, digits, punctuation, spaces, line breaks, mentions and hashtags count at face value on both sides.
In one sentence: against X, this checker reads low on drafts heavy in single-code-point emoji or CJK, and it generally reads high on link-heavy ones. Joined emoji sequences are the exception, where no direction is stated: they are several code points here, and platforms disagree on how to charge them, as the code-points guide explains. Mixed drafts pull both ways at once, which is why the page does not try to net them out.
Worked drafts, counted by the engine
Every number in this section is produced at build time by the same limitCheck
function the checker runs, called with a limit of 280 on the draft shown; none is typed in by
hand. What X's own composer would report is not stated, because this site does not model that figure
— only the direction it would move.
A plain draft. "Office hours move to Thursday this week. Bring the draft you want read, not the one you want praised. We go line by line, and the first ten minutes are reserved for the questions nobody asked in the meeting." — the checker reads 207 code points, 73 remaining of 280. No links, no emoji, no CJK: every character is face value under X's rules too, so this is a draft where the checker's margin is the whole story.
Mentions, hashtags and line breaks. "@sumvia #charlimit" counts 18 code points: the @ and the # are characters like any other, and so is the space. Two short lines separated by a line break count 17 — the break itself is one code point.
A draft with a link. "New write-up: how we cut the build from twelve minutes to ninety seconds without touching the bundler. Before-and-after config, the dead ends, and the one flag that mattered: https://example.com/engineering/build-time-twelve-minutes-to-ninety-seconds" — the checker reads 250 code points, 30 remaining. The URL on its own is 75 characters as written, and X bills any URL at 23. So on this draft the checker reads high: the real margin at X is larger than 30, not smaller.
A draft with emoji. "Launch day 🎉🎉🎉 Thank you to everyone who tested the beta, filed bugs, and argued with us about the defaults 🙏 We shipped the version you asked for 🚀" — the checker reads 148 code points, 132 remaining. The emoji by themselves are 5 code points here, and X weights each at 2. The checker therefore reads low on this draft. With 132 to spare, the undercount does not matter; the next draft shows when it does.
A borderline draft. "Doors open at seven, talks start at half past 🎤 Bring a laptop if you want to follow the live demo, and a question if you want to derail it 😄 Coffee is sorted ☕ Parking is not, so the train is the better bet 🚆 Say hello at the desk when you arrive, we will have name tags ready 👋" — the checker reads 279 code points, 1 remaining of 280. Inside the limit, by the meter. But the draft contains 5 emoji, each counted once here and weighted 2 at X, and a margin of 1 is smaller than that emoji count. The meter is accurate about code points and the draft is still not safe at X. Cut an emoji or a clause, or verify in the composer before posting.
A CJK draft. "今日は雨なので会議はオンラインに変更します。" — 22 code points. Each character is one here and weighted 2 at X, so the checker reads low on this draft by the same mechanism as emoji.
An over-limit draft. "A long reply, written in one breath: the proposal is sound, the timeline is not, the budget line for testing is missing entirely, the rollout plan assumes a team we do not have yet, and the risk register lists nothing that could actually go wrong. Rewrite the second half and send it again before Friday." — 304 code points, which the checker reports as 24 over the 280 limit. Plain text, so no skew is expected: this draft needs cutting under either count. It is the drafts just inside the line that need the direction rule.
How to read a borderline draft
Treat the checker as a drafting aid. Write against the live meter; when the remaining count gets small, stop reading the number alone and read it against the draft:
- Count the emoji and CJK characters in the draft. If the remaining figure is smaller than that count, the margin the meter shows is not real at X. Cut until it is comfortably larger.
- Note the links. Each URL longer than 23 characters as written is counted in full here and fixed at 23 there, so a tight link-heavy draft has more room than the meter shows — but do not spend that room on emoji and assume the two cancel.
- Joined emoji sequences are the known wrinkle: a family emoji is several code points here, and platforms disagree on such sequences — the code-points guide works through them. A draft that depends on one is a draft to verify.
- For any consequential post within a few characters of the line with emoji, CJK or links in play, paste it into X's composer and trust its meter. That is the final authority.
The common misreadings
Almost every wrong conclusion drawn from a character counter on an X draft is the same mistake: trusting one number to describe two counting regimes. The meter says a link post is over by a handful of characters, and the writer trims a sentence that did not need trimming — when the pasted URL was counted at its full length here and is fixed at 23 at X. Or the meter says an emoji-rich draft has a margin of a few characters, and the writer posts on a figure that was never X's figure. The number was right both times; what it measured was not what X measures.
This site's house example of a silent regime switch comes from the SMS counter: a curly apostrophe pasted from a word processor is not in the GSM-7 alphabet, so one character moves a whole message from the 160 budget to the 70 budget, and nothing looks different on screen. X's weighting is the same shape of problem — a character that looks like one and costs two — which is why the SMS counter shows its detected encoding and the X checker states its direction of skew.
Frequently asked questions
Does the X checker apply the 23-character URL rule?
No. It counts a URL at its as-written length in code points. X's rule — every URL billed at a fixed 23 as of mid-2026 — is described on the checker page and here, not simulated, because deciding exactly which strings X treats as a URL is a server-side judgment this site cannot verify.
Does an emoji count as one or two?
One here, two at X. This site counts Unicode code points, so a single-code-point emoji is one. X's developer documentation weights emoji at 2 as of mid-2026, so the checker reads low on emoji-heavy drafts — every emoji is at least one unit of headroom the meter shows that X does not grant.
Which direction does the checker skew against X?
Low on emoji and CJK (each counted once here, weighted 2 at X), high on links longer than 23 characters as written (counted in full here, fixed at 23 at X). Plain text — letters, digits, punctuation, spaces, line breaks, @mentions and #hashtags — counts at face value under both.
Is the limit still 280?
For standard posts, yes, as of mid-2026: 280 characters, doubled from 140 in 2017. Paying subscribers can post far longer; this site states no figure for paid tiers. When X changes the standard limit, the checker preset and page copy are updated.
Why not just model the weighted count?
Because a model has to guess where X draws its lines — what counts as a URL, which code points X treats as emoji, how joined emoji sequences are charged — and a confident wrong number is worse than an honest count with a stated direction.
What should I trust for a post that is right at the line?
X's own composer. Use the checker to draft and to see your margin, then read that margin against the emoji and links in the post. If the remaining count is smaller than the number of emoji in the draft, the margin is not real at X. The composer's meter is the final authority on any consequential post.
Counting on this site is in Unicode code points; X's weighting (every URL at 23, emoji and CJK at 2, per X's developer documentation as of mid-2026) is described here and on the methodology page, not modeled. Nothing you type is transmitted or stored.