Speed Reading in Japanese, Chinese and Thai
Almost every speed reading tool ever built assumes something it never states: that you can find the words in a sentence by splitting it wherever there is a space.
For English that assumption is invisible because it is true. For Japanese, Chinese, Thai, Khmer, Lao and Burmese it is simply false, and the failure is not subtle. It is not that those languages read badly in a typical speed reader. It is that they do not read at all.
What actually happens
Take the opening line of Natsume Sōseki’s I Am a Cat:
吾輩は猫である。名前はまだ無い。どこで生れたかとんと見当がつかぬ。
There are no spaces in it. There is no space between 吾輩 (wagahai, “I”) and は, the particle that marks it as the subject. A program that splits on whitespace finds nothing to split on, so it concludes the entire passage is one enormous word — and a reader that shows one word at a time dutifully flashes all thirty-three characters at once, then stops.
This is worth sitting with, because it is not a cosmetic bug. In a paced reader, the list of words is the application. Everything downstream is built on it: your position in the book, the progress bar, how long the chapter will take, where a bookmark points, how the pace adapts. If the list has one item, every one of those features is meaningless at the same time.
Why the spaces are missing
They were never there. It is not an omission.
Japanese distinguishes word boundaries a different way — by alternating between three scripts. Content words tend to be written in kanji (猫, “cat”) while grammatical particles and inflections appear in hiragana (は, である). A fluent reader parses the boundary from the script change itself, the way an English reader parses a compound like “bookshelf” without needing a mark between the parts.
Chinese has no such alternation and manages without word spaces entirely; boundaries come from vocabulary and context. Thai runs words together and uses spaces the way English uses commas — to separate phrases and clauses, not words. If you split Thai on spaces you do not get words, you get clauses, which is arguably worse than getting one long string because it looks like it worked.
How you find words without spaces
You need a dictionary, and a way to choose between the readings it allows.
This is a genuinely hard problem in the general case — Japanese segmentation has been an active research area for decades, and ambiguous cases exist where even native readers need context to be sure. But the common cases are extremely well handled, and the important practical point for anyone building or choosing a reading tool is that you do not have to solve this yourself.
Every modern browser already ships with ICU, the same internationalisation library that sits underneath most operating systems, and it includes dictionary-based word breaking for exactly these scripts. It is available to any web page through the Intl.Segmenter API. It costs nothing to download, because it is already there.
Run the Sōseki line through it and you get nineteen units: 吾輩 / は / 猫 / で / ある / 名前 / は / まだ / 無い, and so on. Those are words a Japanese reader would recognise as words. Run an English sentence through the same API and you get exactly what splitting on spaces gave you — which means it can be the single path for every language rather than a special case bolted on the side.
ReadKinetic detects the script from the text itself and segments accordingly. You do not choose a language anywhere, and there is no setting for it.
The number on the screen is also wrong
Fixing the words is necessary but not sufficient, and this is the part most tools would still get wrong even after segmenting correctly.
Reading speed in English is measured in words per minute. Reading speed in Japanese conventionally is not — it is measured in 文字/分, characters per minute, and typical adult reading sits somewhere around 400 to 600.
The reason is that the units are not comparable. A segmented Japanese “word” averages well under two characters, and a great many are single particles like は or で. If a Japanese reader sets a tool to 300 and it means 300 words per minute, the honest translation is roughly 500 characters per minute — a completely different claim about how fast they are reading. Showing “300 WPM” to that reader is not a rounding error. It is a number that means nothing in the frame they use.
So ReadKinetic changes the unit with the script. Open a Japanese book and the speed reads 文字/分, computed from that book’s own average characters per word rather than a hardcoded guess. Open an English one and it reads WPM again.
Three more things that have to change
Segmenting the words and fixing the unit still leaves a reader that looks wrong. Three smaller details matter more than they sound:
The highlighted letter is meaningless for CJK. Speed readers put one character in a contrasting colour, at the optical centre of the word. The theory behind that — the optimal recognition point — comes from research on recognising alphabetic words by their overall shape. A two-character Japanese word has no such shape to recognise, and length-based placement rules put the marker on the second character, which just looks off-centre. Ideographic words should simply be centred.
A Latin font has no Japanese glyphs at all. ReadKinetic ships Old Standard, Outfit and OpenDyslexic, and not one of them contains 猫. Without intervention the browser silently substitutes whatever the operating system offers, which is why CJK text in a themed reader so often looks like it fell out of the design. A CJK webfont is 5 to 15 megabytes and cannot reasonably be bundled, so the honest answer is to name a proper system stack — Hiragino, Yu Gothic, Noto Sans JP, PingFang — and let the device use a font it already has.
The comma is a different character. Punctuation pauses in a paced reader key off marks like . , ! ?. Japanese uses 。 for a full stop and 、 for a comma. Miss the ideographic comma and you lose the most common pause in the language.
See it read
The passage below is Japanese. Notice that it advances one word at a time, that the word sits centred, and that the speed is reported in characters per minute.
Does RSVP even help in these languages?
Honestly: the research base is much thinner here than for English, and anyone who tells you otherwise is guessing.
What can be said with reasonable confidence is mechanical rather than empirical. The costs that a paced reader removes — the return sweep to the start of the next line, regressions back to something you half-read, losing your place — are not specific to the Latin alphabet. They are properties of reading text laid out in lines. A reader of Chinese pays them just as an English reader does.
What is genuinely different is that ideographic scripts carry more meaning per character, so a reader may extract more from each fixation. Whether that makes RSVP more or less useful is not something I can tell you from evidence, and I would rather say so than invent a number.
What this is really about
There is a version of this post that claims ReadKinetic is better at Japanese than everything else. That is not the claim.
The claim is that a great many reading tools fail on most of the world’s readers in a way their authors never see, because the failure only appears in scripts they do not read. Splitting on whitespace is an assumption about English wearing the costume of a general solution. Once you notice it, fixing it costs almost nothing — the dictionary is already in the browser.
If you read in Japanese, Chinese, Thai, Khmer, Lao or Burmese, open one of your own books and see whether it behaves. That is the only test that counts.
Read your own books, in your own script.
ReadKinetic runs in your browser, reads EPUB and PDF, and never uploads anything. English, 日本語, 中文, ไทย and more.
Also worth reading: What Are Eye Saccades? · The Return Sweep in Reading · Does Speed Reading Hurt Comprehension?