Calling UTF-16 length a character count
JavaScript string length reports UTF-16 code units, not user-perceived characters. Joined emoji and supplementary code points can make that number larger than the grapheme count.
Word Counter | Words, Graphemes, Code Points and UTF-8 Bytes
TextRuns in Your Browser (No Uploads)
Count Unicode word-like segments, grapheme clusters, characters without whitespace, sentences, paragraphs, logical lines, code points, UTF-16 code units, UTF-8 bytes, and estimated reading time locally.
What to do next
Continue with a related workflow or open the next tool that usually follows this task.
Workflow guide
Preview Markdown safely before publishing a README or article
A Markdown preview is most useful as a review stage, not as a promise that every destination will render the same document. This workflow keeps the working text in the browser, checks common extended syntax and sanitized raw HTML, treats remote images as an explicit privacy decision, and separates content markup from destination styling. It finishes by testing the exported HTML fragment or original Markdown in the system that will actually publish it.
OpenRelated toolLine Ending Detector for CRLF, LF, and Mixed Text Files
Count original CRLF, LF, CR, and Unicode line separators in a local file.
OpenRelated toolMarkdown Preview and Sanitized HTML Converter
Preview Markdown locally and export sanitized HTML with tables, tasks, code, math, and footnotes.
OpenRelated toolText Analysis Workbench | Frequency, Readability, Tone, and Similarity
Inspect six bounded text measurements locally with Unicode segmentation and explicit limits.
OpenHow to Use This Tool
Preserve the original text or file when exact line endings and bytes matter.
Paste text or load a local TXT, CSV, TSV, LOG, or Markdown file up to 1,048,576 UTF-8 bytes and 200,000 logical lines.
Set the reading rate from 50 to 1,000 word-like segments per minute; this setting changes only the time estimate.
Run the analysis in the Worker and compare words, grapheme clusters, sentences, paragraphs, lines, code points, UTF-16 code units, and UTF-8 bytes.
Review warnings for format characters, U+FFFD replacement characters, mixed line endings, and the limits of CJK reading-time estimates.
Copy or download the report, then confirm which counting unit the destination system actually enforces.
When to Use This Tool
Editorial and academic length checks
Compare the publisher's required word definition with the Unicode word-like total, and retain paragraph, sentence, and line evidence for revisions.
API and storage limit verification
Select the exact grapheme, code-point, UTF-16, or UTF-8 metric used by a database column, API payload, message field, or validation rule.
Localization budget review
Inspect multilingual UI strings where visible characters, code units, and bytes diverge, especially around accents, emoji, and CJK text.
Reading-time planning
Estimate article reading time with a documented rate, then adjust the estimate for code blocks, tables, media, and audience knowledge.
Text-integrity preflight
Detect mixed line endings, format characters, or U+FFFD before an import, comparison, deduplication, or publishing workflow proceeds.
Common Mistakes
Treating whitespace tokens as words in every language
Whitespace splitting treats an entire no-space Japanese sentence as one token. Unicode segmentation is more useful, but its word-like boundaries still are not a universal linguistic or academic definition.
Using the visible-character total for every limit
A platform may cap UTF-8 bytes, UTF-16 units, code points, or rendered graphemes. Using the wrong total can reject valid input or truncate a multi-code-point character.
Ignoring or blindly removing format characters
Invisible joiners and other format characters can be intentional in emoji or scripts, or accidental in copied identifiers. Review them rather than deleting every occurrence automatically.
Publishing an estimated reading time as exact
Reading time is a planning estimate, not a promise. Code, tables, unfamiliar terminology, language, and audience can dominate a simple words-per-minute calculation.
Examples
Two short paragraphs
The blank line separates two paragraphs; the two LF sequences produce three logical lines.
Input
Hello, world!
Second paragraph.Output
4 words; 32 grapheme clusters; 2 sentences; 2 paragraphs; 3 lines; 32 code points; 32 UTF-16 code units; 32 UTF-8 bytes.Combining mark and joined emoji
The decomposed accent and joined family emoji demonstrate why graphemes, code points, code units, and bytes are separate units.
Input
é 👨👩👧👦Output
1 word-like segment; 3 grapheme clusters; 10 code points; 14 UTF-16 code units; 29 UTF-8 bytes; 3 format characters used as emoji joiners.Counting contract and limitations
Word and sentence totals iterate ECMAScript Intl.Segmenter boundaries with the page locale. A word is a segment whose isWordLike flag is true; punctuation and standalone emoji are not manufactured into words.
The main character total uses extended grapheme clusters. The no-whitespace total excludes clusters made entirely of Unicode White_Space characters. This approximates what a reader sees without pretending it is the unit used by every API.
Code points are counted by Unicode scalar iteration, UTF-16 code units use the JavaScript string representation, and bytes are measured after UTF-8 encoding. Lone surrogate code units are rejected rather than silently encoded as U+FFFD.
CRLF, LF, and CR are recognized separately. Each sequence is one logical break, mixed styles are reported, and paragraph blocks are non-whitespace runs separated by at least one blank line.
Estimated reading seconds are rounded up from word-like segments divided by the selected rate. CJK dictionary segmentation is useful for no-space text, but the result and reading rate remain heuristic rather than a linguistic certification.
Analysis is limited to 1,048,576 UTF-8 bytes, 1,048,576 UTF-16 code units, and 200,000 logical lines. It runs in a dedicated Worker with a two-second timeout; source text is not placed in analytics events or external requests.
Frequently Asked Questions
Does one emoji always count as one character?
The main character count uses extended grapheme clusters, so a base letter plus combining mark or a joined emoji can count as one user-perceived character. The report separately shows Unicode code points and UTF-16 code units because software limits may use either unit.
How are words counted in Korean, Japanese, or Chinese text?
Words are Intl.Segmenter word-like segments using the page language as a locale hint. This handles many scripts without spaces better than splitting on whitespace, but dictionary boundaries and editorial word counts can differ by browser, language, and institution.
Why does text ending with a newline include an extra line?
Each CRLF pair, lone LF, or lone CR is one line break. A non-empty input therefore has one more logical line than its number of line breaks, including a final empty line after a trailing break.
Is the reading-time estimate a measured duration?
No. It is a heuristic based on the selected word-like-segments-per-minute rate. Language, sentence complexity, audience, tables, code, and media can change actual reading time substantially.
Which count should I use for an API or platform limit?
Platforms choose different units. A visible grapheme, Unicode code point, UTF-16 code unit, and UTF-8 byte can have different totals. Check the destination specification and use the matching metric in the report.
Is pasted or uploaded text sent to a server?
The browser reads the selected text file and analyzes it in a dedicated Worker. The tool does not upload the text, and analytics records only aggregate run metadata rather than the source content.
What should I do when the replacement-character warning appears?
U+FFFD usually means bytes were decoded with missing or incorrect information before this analysis. Return to the original file bytes and verify the character encoding; counting or normalizing the replacement symbol cannot recover the lost character.
How This Tool Was Verified
Maintained and tested by SimpleWebUtilsReviewed
Method: For “Test a 31-byte display-name field”, we entered the documented fixture in Word Counter and followed “Preserve exact source evidence” before “Measure every plausible unit”. We compared the browser result with the stated output, then reviewed “Assuming character means JavaScript length” and “Truncating with an arbitrary string slice” as separate failure boundaries.
Expected result: The NFC fixture measured 6 graphemes, 12 code points, 16 UTF-16 units, and 31 UTF-8 bytes; the decomposed form measured 32 bytes before normalization and was accepted only under the documented NFC storage contract.
Open the tested workflowRelated workflow guides
Use these focused guides when you need a practical workflow before opening the tool.
Workflow guide
Preview Markdown safely before publishing a README or article
A Markdown preview is most useful as a review stage, not as a promise that every destination will render the same document. This workflow keeps the working text in the browser, checks common extended syntax and sanitized raw HTML, treats remote images as an explicit privacy decision, and separates content markup from destination styling. It finishes by testing the exported HTML fragment or original Markdown in the system that will actually publish it.
Workflow guideAudit text metrics before publishing or comparing drafts
Use this workflow when an editor, researcher, support team, or SEO review asks whether a draft repeats words, contains a target phrase too often, reads easily, sounds negative, or resembles another version. It records the unit, language, normalization, denominator, limits, and interpretation before analysis, then separates deterministic evidence from editorial judgment.
Workflow guidePrepare reproducible text fixtures and decorative samples safely
Use this workflow when a test, mockup, terminal demo, documentation example, or harmless visual experiment needs generated or rearranged text. It separates structural operations from decoration, preserves source and separator behavior, records every seed and limit, and requires a plain-text alternative whenever FIGlet, mirror, upside-down, Braille-subset, or Zalgo output may not survive fonts, assistive technology, search, or copying.
Workflow guideVerify text limits across Unicode counting units
A reliable text-limit check starts from the destination contract, preserves the source representation, measures several Unicode units, includes normalization and invisible-character fixtures, exercises the limit on both sides, and verifies the value after storage or transmission.
Related Tools
Continue with another maintained workflow
Line Ending Detector for CRLF, LF, and Mixed Text Files
Count original CRLF, LF, CR, and Unicode line separators in a local file.
Text
Markdown Preview and Sanitized HTML Converter
Preview Markdown locally and export sanitized HTML with tables, tasks, code, math, and footnotes.
Formatting
Text Analysis Workbench | Frequency, Readability, Tone, and Similarity
Inspect six bounded text measurements locally with Unicode segmentation and explicit limits.
Text
Unicode Normalizer | Compare NFC, NFD, NFKC and NFKD
Normalize Unicode with code-point evidence and explicit compatibility-loss warnings.
Encoding
Inspect and Remove Zero-Width Characters Safely
Detect six zero-width controls, inspect their positions, and remove only approved types.
Text