What a character counter actually counts
A character counter takes a string of text and returns a number. The number depends on how the counter defines a "character", and that definition has gradually become a more interesting question than it sounds. In English-only ASCII text, every character is one byte and one Unicode code point and one screen glyph — three perfectly aligned representations. Once you add emojis, accented letters, ligatures, combining marks, or scripts like Tamil and Devanagari that build characters from multiple code points, the three representations diverge. A counter has to pick one.
Our counter uses JavaScript string length — text.length — which counts UTF-16 code units. For pure-ASCII English, this is identical to the count of letters, digits, spaces, and punctuation. For most European text (German, French, Spanish, Russian), it is also identical to the visual character count because every character maps to one UTF-16 code unit. For Asian languages, the count is usually correct because most CJK characters fit in a single UTF-16 code unit. The counts diverge for emojis (especially family / flag / skin-tone emojis), for some Indic scripts, and for very obscure characters in the supplementary Unicode planes.
This is the same character count that nearly every web platform, web form, and JavaScript-based length-checking tool uses. If your platform's character counter says "180 / 280" for a tweet, our counter will show 180 too. If your CMS shows "150 of 300 character meta description used", our counter shows 150.
Why the counter shows two numbers
The widget displays two character counts: with spaces and without spaces. The distinction matters because different audiences want different counts.
With spaces is the count platforms enforce. Twitter / X allows 280 characters per tweet, including spaces. SMS allows 160 characters in standard GSM-7 encoding, including spaces. Google's meta description display is roughly 150-160 characters, including spaces. Slack message limits, LinkedIn post limits, Instagram caption limits — all include spaces.
Without spaces is the count word processors and academic submissions often enforce. Microsoft Word's Word Count dialog reports both. Many academic abstracts have a "300 character limit excluding spaces" rule. Some journal submission systems separate "characters with spaces" from "characters" — and "characters" usually means without spaces in that context.
In practice: when you're checking against a platform limit, use the with-spaces count. When you're checking against an academic / publisher rule, read the rule carefully — most modern rules now specify "characters with spaces" but legacy rules often mean without spaces.
How character counting interacts with platform limits
Each platform has its own rules layered on top of basic character counting. The counter shows the JavaScript string length; the platform may apply transformations.
Twitter / X — 280 character limit, but URLs count as 23. A tweet with a URL of any length contributes 23 characters from the URL plus 1 character from the trailing space. Our counter shows the URL's literal length (often 30-50 characters), not the Twitter-rewritten 23. If you're tweeting near the limit, mentally subtract the URL difference.
SMS — 160 characters in GSM-7, 70 in Unicode. GSM-7 is the original SMS character set: basic Latin letters, digits, common punctuation. The moment you include an emoji, an accented Cyrillic letter, an em-dash, or a curly quote, the entire message switches to UCS-2 (Unicode), and the limit drops from 160 to 70 characters per segment. A 175-character message in pure GSM-7 sends as 2 segments at the user's normal SMS rate. The same message with one emoji becomes 3 segments at twice the rate. Our counter does not detect GSM-7 vs Unicode — it only shows the character count.
Google meta description — recommended ~150-160 chars. Google's actual display length varies with screen width and search query. A meta description longer than ~155 chars usually gets truncated in desktop search results. Our counter is the right tool for staying within range; the SEO truth is that you should aim for 150 characters that summarise the page well, not 155 that fill space.
Instagram caption — 2,200 character limit. Instagram counts every character including spaces, and emojis count as one character each (most of them). Hashtags count toward the limit.
LinkedIn post — 3,000 characters. Similar rules to Instagram — every character counts, emojis are typically one character.
Slack message — 40,000 characters per message. Generous limit, but Slack truncates long messages in the channel preview at around 1,000 characters and shows a "See more" expander. Practical limit is shorter than the technical limit.
When the JavaScript string-length count is wrong
Three situations produce divergence between our counter and what a platform actually counts.
Composite emojis count as multiple in JavaScript. A family-of-four emoji (👨👩👧👦) is constructed from four single-person emojis joined by zero-width joiners (ZWJ). JavaScript counts this as roughly 11 UTF-16 code units. Twitter counts it as 2 (their internal weighting). Instagram counts it as 1 in user perception. Our counter shows the JavaScript count, which is the most conservative — if your text fits under the limit per our count, it almost certainly fits per any platform count.
Skin-tone emoji modifiers count as 2 in JavaScript. A waving-hand emoji with a skin tone (👋🏽) is the base emoji plus a skin-tone modifier joined together. JavaScript: 4 code units. Most platforms: 1 emoji = 1-2 characters. If your text is heavy with skin-tone emojis, our counter will read higher than most platforms.
Some legacy systems strip Unicode entirely. Older email gateways, some SMS providers, and certain SQL databases substitute "?" for any non-ASCII character. Our counter shows what JavaScript sees in the browser, before any transmission encoding. If you're targeting a legacy system, test through it.
Why the counter is right for most uses anyway
Despite the edge cases, JavaScript string length is the right default for nearly all character-counting use cases in 2026 because:
- Almost every web form, social platform, and CMS uses the same JavaScript-based counter under the hood. If your text fits on Twitter's website, it fits in our counter at the same number.
- The edge cases (composite emojis, skin tones) push the count UP, not down — meaning if our count says 280, the platform will not say 281.
- For ASCII-only text (most English, most digits, most code), the count is exact.
- For European text (Cyrillic, accented Latin), the count is exact.
- For CJK text (Chinese, Japanese, Korean), the count is exact for the vast majority of characters.
The cases where our count is materially wrong are: emoji-heavy social posts (off by a few), Indic-script text with combining marks (off by a few), and supplementary-plane characters like obscure Chinese variants (off by a few). For copywriting, social media, academic submissions, SEO, and form-input planning, the count is reliable.
Common gotchas
The textarea may include trailing whitespace from a paste. Pasting from Microsoft Word often appends a final newline. Our counter includes that newline in the with-spaces count and ignores it in the no-spaces count. If you see a "1 character difference" between the counter and the platform, check for trailing whitespace.
Tab characters count as one character each. A tab is \t in JavaScript — one character. In the with-spaces count, tabs are included. In the no-spaces count, they are excluded (\s matches tabs).
Multiple consecutive spaces all count. "hello world" with two spaces is 11 characters (with spaces) and 9 (without). Some users expect "double spaces" to collapse — they don't here.
Curly quotes vs straight quotes. "Hello" with curly quotes is 7 characters (the open and close quotes are different code points). "Hello" with straight quotes is also 7 characters. The difference shows up only in encoding-sensitive contexts (SMS GSM-7 doesn't include curly quotes, so curly quotes drop SMS to Unicode encoding and the limit drops from 160 to 70).
Newlines vs paragraphs. Each \n is one character. A paragraph break (blank line between paragraphs) is \n\n — two characters. Markdown editors often display a paragraph break visually but encode it as two newlines.
When to use a different tool
For Twitter-specific character counting (with the 23-char URL rule), use Twitter's own composer — it does the URL substitution automatically.
For SMS character counting with GSM-7 vs Unicode detection, use a dedicated SMS tool like Twilio's character counter — it tells you whether your message fits in GSM-7 or has been pushed to Unicode.
For grapheme-cluster counting (true visual character count, including composite emojis as one), use a Unicode-aware library like Intl.Segmenter or grapheme-splitter. Our counter is JavaScript string length, not grapheme clusters.
For language-specific counting (Chinese characters, Japanese kana / kanji, Arabic), use a script-aware tool that distinguishes character types. Our counter treats all code units uniformly.
A reference grid for common limits
For quick mental access to common character limits:
- Twitter / X: 280 (Premium: 25,000)
- SMS GSM-7: 160 per segment
- SMS Unicode: 70 per segment
- Google meta description: ~155 before truncation
- Google title tag: ~60 before truncation
- LinkedIn post: 3,000
- Instagram caption: 2,200
- Slack message: 40,000
- Discord message: 2,000
- WhatsApp status: 700
- Facebook post: 63,206 (yes, really)
- Reddit text post: 40,000
- YouTube description: 5,000
- Email subject line (Gmail truncates around): ~70
Use the counter above to check your text against any of these. The number you see is the JavaScript code-unit count, which matches what nearly every platform measures.