Counting Characters Against a Limit Someone Else Set

Four numbers for one emoji

Take the family emoji made of a man, a woman, a girl and a boy. It is one thing on screen, one press of Backspace deletes it, and one text cursor step moves past it. Underneath it is four people-emoji separated by three copies of an invisible control character, U+200D, the zero-width joiner. Measured four ways, that string is 1 grapheme cluster, 7 code points, 11 UTF-16 code units and 25 UTF-8 bytes. Nothing is wrong with any of those numbers; they answer four different questions.

The grapheme cluster is the user-perceived character, and Unicode defines the boundaries between them in a technical annex, UAX #29, precisely because "what a reader thinks of as one character" is not obvious enough to leave to each program. The code point is the numbered entry in the Unicode catalogue. The UTF-16 code unit is a sixteen-bit slot, and anything above U+FFFF needs two of them — that is the number JavaScript, Java and C# report when you ask for a string's length. The UTF-8 byte is what actually travels down the wire and sits in a database column.

What this tool counts, exactly

The frequency counter loops over the input with a for-of loop, which in JavaScript walks code points rather than sixteen-bit units. So it counts code points, and you can see it do so. Paste the family emoji with the default settings and the output is five rows: a blank-looking row with the count 3, then four rows with the count 1 each. The blank row is the zero-width joiner. Sum the column and you get 7, which is the code-point count, not the 1 you would call it if asked how many characters you had pasted.

Two defaults change the arithmetic before you see it. Skip whitespace is on, so spaces never appear in the table: "Merci beaucoup !" is 16 characters but produces 11 rows summing to 14, because the two spaces are dropped. Ignore case is on too, and it folds pairs together — which is usually what you want, and occasionally produces something strange. The Turkish capital İ lowercases to a lowercase i plus a separate combining dot, so the table gains a row whose key is two code points long. The tool never claimed the row key was a single character; it is whatever the lowercase mapping produced.

And it prints no total. The output is a two-column table of character and count, sorted by count then alphabetically, and the number you probably came for is the sum of the second column. If you want the four counts side by side without arithmetic, the UTF-8 byte counter on this site prints graphemes, code points, UTF-8 bytes, UTF-16 units, words and lines in one go — it exists because those numbers disagree, and its own comment says so.

The one-paste test that tells you which counter you are facing

Paste one family emoji into the field with the counter, and read the counter. If it says 1, it counts grapheme clusters. If it says 7, it counts code points. If it says 11, it uses the language's native string length, which means UTF-16 code units — JavaScript, Java or C#. If it says 25, it is counting UTF-8 bytes, and the limit is really a byte limit. Four possible answers, four different systems behind the box, and the test takes one paste.

There is a second half to the test, and it matters more: the counter you see in the browser is not necessarily the one that decides. A front-end counter is almost always JavaScript's .length, while the rejection you get on submit comes from a server, a column definition or a downstream API with its own idea. If the box lets you type 500 and the save fails at 480, the two ends are counting differently and the shorter one wins. Type the text, save it, then reload the page and look at what came back — truncation is easier to see than to predict.

SMS: 160 characters, or 70, and one apostrophe decides

The short message service carries up to 140 octets of user data. Pack that with the GSM 7-bit default alphabet and you fit 160 characters; encode it as UCS-2, two bytes per unit, and you fit 70. When a message is too long it is split, and each part gives up room to a small header that says which part it is: that leaves 153 seven-bit characters or 67 UCS-2 units per segment. Nothing about this is negotiable, and every bulk-SMS price list is built on it.

The interesting part is what is in that 7-bit table, because a single character outside it flips the whole message to UCS-2 and more than halves the capacity. The table does hold a generous set of accents — è é ù ì ò à ä ö ü ñ å æ ø ß, plus Ä Ö Ü Ñ É Å Æ Ø Ç — along with ¡ ¿ § and a handful of currency symbols. It does not hold á, í, ó or ú, and it does not hold ã or õ. So a Spanish message containing "está" or "aquí", or a Portuguese one containing "não", is a 70-character message, not a 160-character one, and nothing on the screen tells the sender.

The specification anticipated this and defines national language tables — Spanish gets a single-shift table, Portuguese gets both a single-shift and a locking-shift one. A single-shift character costs two of your seven-bit slots instead of one, and both ends have to implement the mechanism. In practice most gateways do not try, and drop to UCS-2 instead. The same escape mechanism is why a small set of common symbols already cost two slots each in plain messages: the caret, the braces, the square brackets, the backslash, the tilde, the vertical bar and the euro sign all live in the extension table, not the main one. And the typographic apostrophe your word processor inserted when you typed an ordinary one is not in either table.

The meta description is measured in pixels, not characters

Every SEO checklist gives a character range for the meta description. Google's own documentation gives none: it says there is no limit on how long a description can be, that the snippet is generated from the page and sometimes from the description, and that snippets are trimmed to fit the result. Fitting is a matter of rendered width, so a description full of wide letters is cut sooner than one of the same character count made of narrow ones, and the mobile result gets less room than the desktop one.

The practical consequence is not to abandon a character budget but to stop treating it as a rule. Put the part that must survive in the first half of the sentence, then check the real result rather than the count. And be aware that Google frequently rewrites the description entirely when it judges the page content answers the query better — a truncated description you never wrote is a different problem from a truncated one you did.

Two spellings of the same word, two lengths

There is a last trap that has nothing to do with emoji. The letter é can be one code point, U+00E9, or two: a plain e followed by a combining acute accent. They look identical, they mean the same thing, and they have different lengths — 1 code point and 2 bytes against 2 code points and 3 bytes. Most keyboards produce the first; some operating systems, some scanners and a great deal of copied-and-pasted text produce the second. Run the decomposed form through the frequency counter and it comes back as two rows, one of which is a bare accent sitting on nothing.

If a length check is failing on text that looks the right length, this is the first thing to test. Normalising to the composed form before counting fixes it, and it is one call in every language that ships a Unicode library. Do it before you count, before you store, and before you compare two strings for equality — the same word in two normalisation forms is not equal by any byte comparison.

Frequently asked questions

Why does the frequency table have a blank row?

Because a character that renders as nothing is still a character, and the counter reports it honestly. In the family emoji that row is U+200D, the zero-width joiner, which appears three times: it is what glues the four people into one picture. Variation selectors behave the same way — the little U+FE0F that turns a monochrome symbol into a colour emoji is invisible and counted. A blank row with a number beside it is the tool telling you that your text contains something you cannot see, which is exactly what you want to know before pasting it into a field with a limit.

Does one emoji really halve my SMS?

More than halve it. A message is encoded in one alphabet from end to end, so a single character outside the GSM 7-bit table forces the whole message into UCS-2, and capacity falls from 160 characters to 70. It is worse for emoji specifically: anything above U+FFFF takes two UCS-2 units, so a plain smiling face costs two of your 70 and the family emoji costs eleven. Six of those emoji and one word will not fit in a single segment. If your bulk-SMS bill jumped without the copy getting longer, look for a curly apostrophe or an accent the table does not carry before you look anywhere else.

My form says 500 characters. Which 500 does it mean?

Test it rather than guess. Paste one family emoji and read the counter: 1 means grapheme clusters, 7 means code points, 11 means UTF-16 code units, 25 means UTF-8 bytes. In plain ASCII all four agree, which is why the difference only shows up when a real user pastes a name with an accent or an emoji into the box. If you own the form, count grapheme clusters for the user-facing number and validate against whatever the storage layer really enforces, then set the visible limit to the smaller of the two. If you do not own it, assume the smallest plausible answer and leave slack.

Is a database VARCHAR(500) five hundred bytes or five hundred characters?

In the mainstream relational databases the declared length is in characters, not bytes — but the limits around it are in bytes, and that is where people get caught. A row has a maximum size in bytes, an index has a maximum key size in bytes, and a four-byte-per-character encoding multiplies both. So the column accepts your 500 characters and the index on it refuses to be created. Byte limits are more common outside the database: HTTP header values, message-queue payloads, object-storage keys and plenty of third-party APIs are all specified in bytes. When the documentation says bytes, count bytes.

How many characters should a meta description be?

There is no documented number, and any specific one you have been given was measured from search results rather than published as a rule. Google's guidance is that descriptions have no length limit, that snippets are drawn from the page as well as the description, and that they are trimmed to fit — fitting being a matter of rendered width in a layout that differs between phone and desktop. The useful habit is to front-load: put the claim, the number or the differentiator in the first clause, and treat everything after it as expendable. Then look at the actual result in a real search and adjust from what you see.