What this tool calculates
The calculator reports a character-oriented count based on Unicode code points and a storage-oriented count based on UTF-8 bytes. Internally, the verified helper also distinguishes UTF-16 code units, which explains why a JavaScript string's native length can differ from the visible result for some emoji and supplementary characters.
“Character” has several meanings in computing. A code point count is more Unicode-aware than counting UTF-16 units, but it is still not always the number of user-perceived grapheme clusters.
Inputs
Enter or paste any text, including spaces, line breaks, emoji, combining marks, and non-Latin scripts. The calculation occurs in the browser and does not need to send the text to a length service.
Preserve exact line endings when a byte limit matters. A Windows CRLF line break uses two code points and two UTF-8 bytes, while an LF break uses one. Unicode normalization can also change the code-point and byte counts without changing the apparent text.
Method and formula
The code-point count iterates the string by Unicode code points rather than indexing raw UTF-16 units. The UTF-16 count is the language runtime's code-unit length. The byte count encodes the string as UTF-8 and counts the resulting octets.
Basic ASCII characters use one UTF-16 unit and one UTF-8 byte. Many accented characters use one code point but two UTF-8 bytes. Supplementary emoji commonly use one code point, two UTF-16 code units, and four UTF-8 bytes.
A grapheme such as an emoji sequence joined with zero-width joiners can contain multiple code points while appearing as one symbol. This tool does not apply grapheme segmentation.
Worked example
Enter A😀é.
- Unicode code points:
A,😀, andé, for a total of 3. - UTF-16 code units: 1 for A, 2 for 😀, and 1 for é, totaling 4.
- UTF-8 bytes: 1 for A, 4 for 😀, and 2 for é, totaling 7.
The visible calculator reports 3 characters and 7 bytes. The documented UTF-16 value of 4 explains why a naïve JavaScript .length count would disagree.
How to interpret the result
Use code points when validating a protocol or data rule explicitly defined in code points. Use UTF-8 bytes for payload, database, or API limits defined in encoded bytes. Neither should be substituted for a limit defined in grapheme clusters, display width, SMS segments, or font glyphs.
When enforcing a product limit, document the unit and normalization form. A user should not lose text merely because the interface says “characters” while the backend rejects bytes.
Accuracy and limitations
The byte count specifically uses UTF-8; UTF-16, UTF-32, legacy encodings, compression, escaping, JSON syntax, and transport framing have different sizes. The tool does not normalize text or count grapheme clusters, words, lines, columns, glyphs, or rendered width.
Visually identical strings can have different encodings—for example, a precomposed accented letter versus a base letter plus combining mark. Security-sensitive identifiers require a documented Unicode policy beyond length alone.
Sources
- Unicode Standard, Chapter 2: General Structure distinguishes code points, encoding forms, and user-perceived text elements.
- WHATWG Encoding Standard defines the UTF-8 encoding behavior used by modern web-platform text processing.
Editorial record
Author: SoupCalc Editorial Team
Last reviewed: August 14, 2026
Review scope: Code-point iteration, UTF-16 surrogate behavior, UTF-8 encoding, grapheme limitations, standard references, and the A😀é counts of 3, 4, and 7 were checked.