Characters, Code Points and Emoji

The character counter reports one number for characters and another for characters without spaces, and both are counts of Unicode code points. That one sentence settles most questions about the counter, but it also raises the ones this guide answers: what a code point is, why a single emoji can be one code point or several, why a space or a line break counts, and why another tool can look at the same text and report a different total without either tool being wrong. Every example count below was computed at build time by the engine the counter runs, from short example strings written for this page.

What a code point is

Unicode assigns every character it defines a number, called a code point β€” one for the letter a, one for the accented Γ©, one for the space, one for the line break, one for the thumbs-up emoji. A text is a sequence of those numbers, and the counter's characters figure is the length of that sequence. Nothing is filtered out: punctuation counts, spaces count, and an invisible character counts as surely as a visible one. The engine does this literally. It walks the text one code point at a time and tallies them, rather than asking the programming language for its native string length. That distinction sounds like a detail; it is the entire reason two counters can disagree, and the section on UTF-16 below comes back to it.

For ordinary text the code-point count matches what you would count by hand. "Lunch at noon?" is 14 code points β€” every letter, both spaces, and the question mark, each exactly one. Accented letters typed normally are no different: Γ© is one code point, so the accent adds nothing. The exceptions, and they are real, come from emoji and from accents that arrive in a decomposed form; both are covered below.

Spaces and line breaks count

A space is a code point, so it counts, and the same goes for a tab and a line break. The with-spaces figure is therefore the honest measure of how much text is there. The without-spaces figure removes every whitespace code point first β€” spaces, tabs, and line breaks alike β€” and counts what remains; it exists because some conventions measure text by its visible characters, and the counter reports both because both are asked for.

Take a two-line note: "Pack list:↡sunscreen, hat, keys πŸ”‘". The counter reports 33 characters with spaces and 28 without. The gap of 5 is the whitespace: the spaces between the words plus the single line break between the lines. A line break typed into the counter is one code point. Text pasted from a Windows file can instead carry a two-character break β€” a carriage return followed by a newline β€” and because the character count does not normalize breaks before counting, that pair counts as two: "Line one↡Line two" with a Windows break is 18 code points where the same text with a plain break is 17. The line counter does normalize the pair before splitting, so the line count is unaffected either way; the sentences, paragraphs and lines guide covers that side. If text that appears to fit a field is rejected, the characters you cannot see β€” a trailing space, an empty line at the end, a Windows break β€” are the usual explanation.

Emoji: one picture, several code points

Emoji are where the code-point count and the eye part company, because a single picture on screen can be assembled from several code points. The engine's answers for four cases:

  • πŸ‘ on its own is 1 code point.
  • πŸ‘πŸ½ is 2: the base emoji plus a skin-tone modifier, a separate code point that the renderer applies to the one before it.
  • πŸ‡―πŸ‡΅ is 2: a flag is a pair of regional indicator characters, and the renderer draws the pair as one flag.
  • πŸ‘¨β€πŸ‘©β€πŸ‘§ is 5: person emoji joined by invisible joiner characters into a single family glyph, each person and each joiner a code point of its own.

The mechanism is the same throughout: the counter makes no attempt to count the pictures on your screen. It counts code points and says so, and the extra code points in a modified or joined emoji are genuinely present in the text, not an artifact of counting. In context the effect is small but visible. "Lunch at noon? πŸ‘" is 16 characters. Swap in the skin-toned version β€” "Lunch at noon? πŸ‘πŸ½" β€” and the count becomes 17, 1 more, though nothing changed on screen but a color. "Landing in πŸ‡―πŸ‡΅ on Friday" is 23 characters, the flag contributing 2. "Beach day with the πŸ‘¨β€πŸ‘©β€πŸ‘§" is 24, of which the family emoji alone is 5.

Why the same text has two character counts

Some platforms report a different figure for the same text, and the reason is the second convention the methodology page names: counting UTF-16 code units instead of code points.

UTF-16 is the way many programming environments, including the one this site's engine runs in, hold text in memory. It represents each code point as either one or two fixed-size units. Most characters β€” the letters of most alphabets in everyday use, digits, punctuation, accented letters, and many symbols β€” fit in one unit. Code points assigned further along, which is where most emoji live, do not fit and are stored as two units, a pairing known as a surrogate pair. A language's native string length counts those units, because units are what it actually has in memory, and a platform whose counter takes that length as the character count will charge two for most emoji. Nothing is wrong with either number; they answer different questions. The code-point count answers how many characters the text contains, and the unit count answers how much room the text takes in that encoding.

The engine on this site contains both counters, which makes the comparison direct. The character counter uses the code-point walk. The engine's SMS function, written for a messaging convention that genuinely measures in UTF-16 units once any character outside a small basic alphabet appears, switches to counting those units β€” its own documentation notes that most emoji cost two there. This guide uses that function purely as a unit counter; the message arithmetic it also reports is a separate topic. Running the sentences above through both:

Text Code points UTF-16 units Difference
"Lunch at noon? πŸ‘" 16 17 1
"Lunch at noon? πŸ‘πŸ½" 17 19 2
"Landing in πŸ‡―πŸ‡΅ on Friday" 23 25 2
"Beach day with the πŸ‘¨β€πŸ‘©β€πŸ‘§" 24 27 3

The difference column is the number of code points in each string that need a surrogate pair. In "Lunch at noon? πŸ‘" that is the thumbs-up alone, so the conventions differ by 1. In "Lunch at noon? πŸ‘πŸ½" both the base and the modifier need a pair, so the difference is 2. The flag's two regional indicators each need a pair (2), and the family's person emoji each do while its joiners do not (3). Plain letters, spaces, and line breaks are one unit each under both conventions, so on a text with no emoji the two counts agree exactly.

Accents that look the same and count differently

One more case produces two counts from what looks like one text. An Γ© can be stored as a single composed code point, which is what most keyboards produce, or as a plain e followed by a combining accent β€” two code points that render identically. The character counter counts what is there: "cafΓ©" with a composed Γ© is 4 code points, and the decomposed spelling is 5. The letter counter takes a different path. It normalizes text to Unicode NFC first, which folds the decomposed pair into the composed letter, so it reports 4 characters for the composed spelling and 4 for the decomposed one. Neither is a mistake; each page states its convention, and the letters and normalization guide explains when the difference shows up in practice and the one edge β€” a combining mark with no composed form β€” that normalization cannot fold.

Reading the count when it matters

A few practical consequences follow. The with-spaces code-point count is the figure to treat as the baseline size of a text; the without-spaces figure answers a narrower question. When a platform's own counter disagrees with this one near a limit, the platform's counter is the one that will enforce, so it wins β€” and when that counter measures in UTF-16 units, the size of the disagreement will be exactly the number of emoji code points that need a surrogate pair, counting a modified or joined emoji by its pieces, since that is what the two conventions count differently. When emoji do not explain a disagreement, look for the invisible characters: a Windows line break, a trailing space, a decomposed accent. Word counting has its own conventions, covered in what counts as a word, and the guides index lists the rest.

Frequently asked questions

Why does this counter say an emoji is one character when another tool says two?

The two tools use different conventions. This site counts Unicode code points, under which πŸ‘ is 1; the other tool is counting UTF-16 code units, the form some programming environments (including the one this site's engine runs in) hold text in, and under that convention the same emoji occupies 2. "Lunch at noon? πŸ‘" is 16 code points but 17 UTF-16 units. Neither number is wrong β€” they measure different things.

Do spaces and line breaks count as characters?

Yes. A space is a code point and so is a line break, and the with-spaces figure includes every one of them. "Pack list:↡sunscreen, hat, keys πŸ”‘" is 33 characters with spaces and 28 without; the 5 in between are its spaces and its single line break.

Why is a skin-toned emoji two characters?

Because it is two code points: the base emoji and a skin-tone modifier that the renderer applies to it. πŸ‘ is 1 code point and πŸ‘πŸ½ is 2. In UTF-16 units the same pair costs 4, since both pieces need a surrogate pair there.

Why do two identical-looking accented words get different counts?

An accented letter can be stored composed (one code point) or decomposed (a plain letter plus a combining accent β€” two). "cafΓ©" with a composed Γ© is 4 code points; the decomposed spelling is 5. The character counter counts what is there; the letter counter normalizes to NFC first and reports 4 for both spellings.

Does "without spaces" remove line breaks too?

Yes. The without-spaces figure strips every whitespace code point β€” spaces, tabs, and line breaks alike β€” before counting, so a line break never survives into it. That is why "Pack list:↡sunscreen, hat, keys πŸ”‘" drops from 33 to 28, not merely by the number of spaces.

Which count should I trust when a form has a character limit?

The platform's own counter, because it is the one that enforces the limit and it may measure in UTF-16 units where this site measures code points. Use this counter's with-spaces figure as the baseline; if the two disagree, the section "Reading the count when it matters" on this page explains how to trace the gap.

Every example count in this guide was computed at build time by the same engine that runs the character counter, so the copy cannot drift from the code. Counting happens locally in your browser β€” nothing you type is transmitted or stored. Counts are Unicode code points; the UTF-16 convention is explained above. See the methodology page.