Character units and examples
Text length measurement methods vary across platforms and systems, and no single standard applies universally. Always prioritize the explicit requirements specified by your target recipient or service.
If the exact standard is unclear, compare the counts across all available units and verify the text directly within the destination system.
Common measurement criteria include visual characters (grapheme clusters) reflecting perceived glyphs, Unicode code points representing individual character identifiers (used in certain database schemas and APIs), and UTF-16 code units commonly used in JavaScript and standard web forms.
ZeroTools allows you to inspect and switch between these units.
To see how these units diverge, consider the string "A😀 B" followed by a single line feed ("\n"), which spans 2 lines. Visually, it contains 5 grapheme clusters: "A", the grinning emoji, a space, "B", and the newline.
The Unicode code point count is also 5. However, because the emoji "😀" (U+1F600) requires a surrogate pair in UTF-16, the string measures 6 UTF-16 code units.
When encoded in UTF-8, "A", space, "B", and newline each consume 1 byte, while the emoji consumes 4 bytes, totaling 8 UTF-8 bytes.
A more complex example is the character "é" (base "e" plus combining acute accent U+0301), a space, a family emoji formed by joining four individual person emojis with three U+200D (ZWJ) characters (7 code points), and a trailing line feed (spanning 2 lines).
For this input, the visual grapheme count is 4 characters, the Unicode code point count is 11, UTF-16 spans 15 code units, and UTF-8 reaches 30 bytes.
Because counts vary across criteria, checking against your target's specification helps prevent formatting discrepancies.
Submission rules
The submission criteria panel allows you to configure individual exclusion switches for whitespace and line breaks. Enabling whitespace exclusion removes all non-newline spacing characters, including ASCII spaces, full-width ideographic spaces, and tabs.
Enabling newline exclusion removes LF characters. Incoming line breaks (CRLF or CR) are normalized to LF. For example, two trailing newlines ("\n\n") add two counts when line breaks are included, but zero when excluded.
UTF-8 byte count
The UTF-8 byte counter reflects the actual byte length of the body text encoded in UTF-8 via the browser's TextEncoder interface (LF line breaks, no BOM).
It does not include file headers, container metadata, or network transmission overhead. Secondary metrics, such as full-width/half-width classification, manuscript sheet conversion (UTF-16 total divided by 400), and UTF-16 counts excluding whitespace or line breaks, serve strictly as reference values.
Replacement and draft handling
The fixed string replacement utility performs exact, case-sensitive matching without regular expressions. In replacement strings, "$$" inserts a literal dollar sign, and "$&" inserts the matched text.
The clipboard copy feature targets only the body text, though copy operations may fail depending on browser permissions or clipboard access restrictions.
Input text is not automatically saved and will be lost upon refreshing or leaving the page. While input text is never transmitted to external servers for counting, separate network requests may occur in some cases for page assets, external scripts, or analytics.
Text stays in the current page. Copy it before reloading or closing the tab.