Why PDF Word Counts Are Inaccurate for Chinese and Japanese
A tool that had no trouble counting words in an English contract can suddenly return an absurdly low number when you feed it a Chinese or Japanese PDF. That's not because the tool is broken — it's because the very concept of "word count" is defined differently for different languages. This guide checks, at the code level, what algorithm the PDF word counter actually uses, and explains why it goes wrong specifically for Chinese and Japanese.
1. "Word" is defined differently by language
English always puts a space between words, as in "I love you." Korean also has spacing at the eojeol level, as in "나는 너를 사랑해." But Chinese ("我爱你") and Japanese ("私はあなたを愛しています") write whole sentences with no spacing. Word boundaries are a matter of context and dictionary knowledge rather than visual whitespace, so genuinely accurate "word segmentation" needs a separate language-processing engine like a morphological analyzer. Most web-based free tools run on pure text processing without such a heavy engine, so there's simply no way for them to count words accurately in a language that has no spaces to begin with.
2. This tool's actual logic: join with spaces → split on spaces
MODOO HUB's PDF word counter gets the list of text fragments (items) from each page via PDF.js's getTextContent(), then joins all fragments into one string with a single space between each via tc.items.map(x=>x.str).join(' '). Then it counts words with txt.trim().split(/\s+/).filter(w=>w.length>0).length, splitting that string on whitespace. So the entire algorithm is the simple structure "concatenate each text fragment PDF.js handed us with spaces, then split back on spaces." In languages where words (eojeol) are originally separated by spaces, like English and Korean, this nearly matches real word boundaries — but in Chinese and Japanese, which have no spaces in the language itself, the basis for counting shifts entirely from "actual words" to "how many fragments did PDF.js return the text in, due to font, style, and position changes."
split(/\s+/) result counts it as "1 word." Conversely, if the PDF generation program split the sentence into several fragments to adjust font size or letter spacing (e.g. "私は" / "毎日" / "日本語を" / "勉強しています", 4 fragments), a space is forced between each fragment and it counts as "4 words." Both are different from the actual word count (~6–7 by morpheme), and the result even swings depending on how the PDF was made, for the same sentence.
3. Which way does it lean: generally an undercount
As the tool's own description also notes, the "word count" of a Chinese or Japanese PDF tends to come out much lower than the actual number of words. In word-processor output, where a whole sentence is often stored as one text fragment, an entire sentence gets caught as "1 word." Conversely, in a PDF with lots of tables or formatting, or a design document with fine per-character letter spacing, the text fragments are chopped fine and it can even count many more "words" than real. In short, for Chinese and Japanese this number can't be trusted in either direction.
4. So what should you look at: character count is safer
For languages without spaces, using character count (excluding spaces) as the volume metric instead of "word count" is far more reliable. Character count just measures the length of the entire extracted string, regardless of how many fragments PDF.js split the text into, so it's not affected by the fragmentation method. This tool actually provides, per page, chars (character count including spaces) and charsNoSp (excluding spaces) separately alongside the word count. When comparing the volume of Chinese/Japanese documents or estimating translation/typesetting rates, using this character-count column rather than word count is the practically correct choice. Note that Korean, with its eojeol-level spacing, makes this tool's method somewhat valid, but as an agglutinative language where multiple morphemes combine into one eojeol, it doesn't perfectly match the English notion of a "word" either.
5. Use it alongside other document-volume metrics
When document volume is tied directly to money — translation quotes, manuscript fees, print run estimates — it's safer to cross-check several metrics rather than rely on word count alone. To first gauge rough scale by page count, a PDF page counter is fast, and if you want to pull the whole source text and re-verify with another program (e.g. a word processor's own character/word count), you can extract the source with PDF → TXT conversion and paste the output into a separate tool to cross-check.
Frequently Asked Questions
Q. Should I not trust the word count of a Chinese or Japanese PDF at all?
A. Treat it as a rough reference only. It's not an accurate value — it depends on how many fragments PDF.js split the text into, so the same content can give very different numbers depending on the PDF generation program.
Q. Is Korean accurate?
A. Closer to the real word (eojeol) count than English or Chinese/Japanese, because Korean has spacing between eojeol. But an eojeol with an attached particle can't be treated identically to the English notion of a "word," so it's not a perfect match.
Q. What should I use to check the volume of a Chinese or Japanese document?
A. Checking by character count (excluding spaces) is far more reliable than word count. This tool also provides per-page character-count statistics.
Q. Why not use a morphological analyzer?
A. A morphological analyzer is heavy processing that needs per-language dictionaries and models, which doesn't fit a lightweight free tool that runs instantly in the browser. For accurate morpheme-level analysis, use a dedicated language-processing library or service separately.