Paste, type, or revise
Measure the structure and pace of a draft
The interactive workspace reports several units side by side. Choose Auto for the browser locale or explicitly select English, Korean, Japanese, Chinese, or Thai when a reproducible language assumption matters.
Loading the word counter…
Enable JavaScript to analyze text. The segmentation method, structural definitions, and timing guidance below remain available.
Boundaries, not whitespace
How locale-aware word counting works
A simple text.split(/\s+/) recipe treats every run between spaces as a word. That breaks down for writing systems that do not routinely put a space between every word, and it gives accidental meaning to punctuation and repeated separators. This counter asks Intl.Segmenter for word segments and counts segments the implementation marks as word-like.
The selected locale supplies an explicit segmentation context. Auto resolves through the browser's locale negotiation; the named choices request en, ko, ja, zh, or th. The same interface uses sentence granularity for sentence boundaries. See the ECMA-402 Intl.Segmenter definition and Unicode Standard Annex #29 for the standards behind the API and default boundary rules.
Those standards do not promise one eternal total for every input. Unicode data, locale tailoring, dictionary segmentation, and the implementation-defined isWordLike classification can change among browser engines and releases. Record the locale, browser, and rules when a count is part of a contractual publishing or billing workflow.
- Words
- Locale-aware segments classified by the browser as word-like.
- Sentences
- Nonblank segments returned by locale-aware sentence boundary analysis.
- Paragraphs
- Nonblank blocks separated by one or more blank lines.
- Lines
- Logical lines separated by recognized Unicode line-break characters.
- Timing
- Word count divided by the selected reading or speaking rate.
Four related measurements
Words, sentences, paragraphs, and lines answer different questions
Empty input has zero lines. Once text exists, every recognized break ends one line and begins another, so a trailing break deliberately adds an empty final line. In this interface, HTML textarea behavior converts CRLF and CR to LF before the JavaScript value is analyzed; the logical line total remains the same, but byte and code-unit comparisons must account for that conversion.
A transparent heuristic
Estimate reading and speaking time with an adjustable pace
Reading time and speaking time are calculated from the same word total but use separate words-per-minute settings. The arithmetic is intentionally simple: words divided by words per minute. Raising the rate shortens the estimate; lowering it lengthens the estimate.
A rate is not a property of the document. Dense technical prose, unfamiliar names, equations, on-screen demonstrations, audience questions, dramatic pauses, and a language learner's pace all move real duration away from a generic default. Use the controls to model the specific reader or presentation, then rehearse anything with a hard time slot.
For multilingual text, word segmentation and delivery pace are separate choices. Selecting Japanese or Thai changes how boundaries are requested; it does not claim that one universal WPM value makes different languages directly comparable.
Word counts estimate editorial length. Usernames, messages, database fields, and API payloads often specify graphemes, UTF-16 units, code points, or bytes.
Open the Character Counter →Make the contract reproducible
Why a locale and engine version belong beside a formal count
- 1
Preserve the source
Count the exact draft that will be published. The tool does not normalize Unicode, fold case, or rewrite punctuation after receiving the textarea value; browsers expose CRLF and CR line endings there as LF.
- 2
Record the locale
Use a named locale rather than Auto when another reviewer or build system must reproduce the assumption.
- 3
Test disputed examples
Keep examples with contractions, hyphens, abbreviations, emoji, and scripts without spaces as regression cases for the chosen environment.
ECMA-402 deliberately leaves some boundary details to the implementation and its internationalization data. A server library, desktop editor, search index, and browser can all be standards-conforming yet disagree on an edge case. If an external submission portal is authoritative, its published rules and final displayed total take precedence over this planning tool.
The current browser string stays local
Count locally without Unicode normalization
Analysis runs in the current browser tab. LiveParse does not intentionally send the entered text to a counting endpoint or create a server-side document history. That makes the page useful for drafts that should not be pasted into an unknown remote API, while browser extensions, clipboard managers, device backups, and screenshots remain separate privacy boundaries.
The tool does not apply NFC, NFD, NFKC, or NFKD normalization to the current textarea value. A precomposed accented letter and a decomposed base-plus-mark sequence therefore remain distinct. HTML textarea behavior separately converts CRLF and CR line endings to LF before analysis; inspect code-point, UTF-16, and UTF-8 units with the Character Counter.
JavaScript strings can also contain an unpaired UTF-16 surrogate. Locale segmentation can analyze the string as held by the engine, but strict UTF-8 encoding cannot preserve that isolated code unit as a Unicode scalar value. The related character tool reports UTF-8 bytes as unavailable for such input instead of quietly presenting a replacement-based byte total.
Grapheme clusters, code points, UTF-16 code units, and UTF-8 bytes are distinct units with different limit and slicing behavior.
Compare Unicode length units →Questions answered
Word counter FAQ
What does this word counter count?
It counts word-like segments and sentences with the selected locale, then separately counts nonblank paragraphs and logical lines. It also estimates reading and speaking time from the word count and the chosen words-per-minute rates.
Why can two word counters produce different totals?
Word boundaries are not universal. Counters may split punctuation, contractions, hyphenated terms, emoji, or scripts without spaces differently. This tool uses the browser's locale-aware segmentation data, so the selected locale and browser engine can affect edge cases.
Can it count Chinese, Japanese, Korean, or Thai text?
Yes. Choose Chinese, Japanese, Korean, or Thai, or leave the locale on Auto to use the browser preference. Locale-aware segmentation is more appropriate than splitting only at spaces, although results can still vary with the browser's Unicode and dictionary data.
How are paragraphs and lines counted?
A paragraph is a nonblank block separated by one or more blank lines. The analysis rule recognizes CRLF as one break and also recognizes CR, LF, NEL, line separator, and paragraph separator. The HTML textarea exposes CRLF and CR as LF before analysis; empty input has zero lines, and a final break creates an empty final line.
How are reading and speaking times calculated?
Each estimate divides the word count by the selected words-per-minute rate. The rates are adjustable because audience, language, difficulty, pauses, and delivery style all change real timing; the result is a planning estimate, not a measured duration.
Is my text uploaded or normalized?
No. Counting runs in the current browser tab and the tool does not intentionally upload the entered text. It analyzes the current textarea value without Unicode normalization, so canonically equivalent spellings can retain different code-point and byte counts. HTML textarea behavior converts CRLF and CR line endings to LF before analysis.