Labs · Book checkup
Will this txt read well?
Check before you commit.
Drop a novel txt: encoding detected, chapters recognized the way a production importer does it, word count, reading time, and how many commutes the audiobook takes. A 30MB tome parses locally — with a progress bar that tells the truth.
Drop a txt here, or click to choose
.txt (UTF-8 / GBK / UTF-16 auto-detected) · up to 64MB
The whole book parses locally in your browser — nothing uploads. Same for a 30MB tome.
The checkup report appears here.
What should you check in a txt file before importing it?
Three things break most imports: encoding (a GBK file read as UTF-8 turns to mojibake), chapter headings the detector can't parse (the whole book collapses into one giant chapter), and stray download-site boilerplate. Drop the file above and all three get checked in your browser — plus word count, reading time, and audiobook length at four speeds — before you commit it to any reader.
Where the chapter rules come from
The detector is a port of the chapter-recognition rules running in our app's txt importer, hardened against real library files: 第N章/卷 families with volume and side-story prefixes, bare numeric headings, bracketed numbers, Chapter N with Roman numerals, prologue and epilogue markers. It also carries the defensive passes those files taught us — download-site tables of contents get dropped as a dense duplicate group, resetting option-style numbering is refused, and prose lines ending like sentences don't become chapters.
Encoding detection runs a chain: byte-order marks, BOM-less UTF-16 by byte pattern, strict UTF-8, damaged-but-mostly-UTF-8, then strict and near GB18030 — each step verified by decode evidence, not file extension.
Where it falls short
This is the rule core, not the whole importer: extreme heading styles (full-width digit soup, punctuation-free chapter lines) recognize worse than the app's full version, and books over 10MB get chapter-scanned only in the first 4 million characters — counts stay exact, and the report says when the cap applied. Big5 and Western single-byte encodings aren't in the detection chain. And epub stays app-side for now; a half-done browser unpacker would lie to you more than this page's honest refusal does.
FAQ
Why did my 2-million-character book come out as one giant chapter?
Chapter detection needs heading lines it can recognize — 第N章 family, numeric headings like "001 Title", Chapter N, prologue markers. If a book uses none of them (or a rare style), everything lands in one chapter, which breaks per-chapter audiobook segmentation and forces AI-continuation context to be cut by raw length. This page ports the core rules of a production importer; the app's full version covers more styles and supports manual splitting.
The preview shows garbage characters — what happened?
The file's encoding is probably outside this page's detection chain. It covers UTF-8 (strict and slightly-damaged), GBK/GB18030, and UTF-16 with or without byte-order marks — the shapes that account for nearly all real novel files. Big5 and Western European single-byte encodings aren't detected here; re-save as UTF-8 in a desktop editor, or let the app's fuller chain handle it.
Why doesn't it take epub?
epub is a zip container: unpacking, xhtml parsing, and spine-order chapter assembly. Doing that half-well in a browser would produce worse answers than not doing it — so this v1 takes txt only and says so. The app's importer accepts epub directly.
How are the reading and listening times calculated?
Reading at 300 characters per minute (Chinese) or 220 words per minute (English books, detected by CJK share). Audiobook length at 250 characters or 150 words per minute for 1× speed — the same conversion our cost calculator uses — plus 1.25×, 1.5× and 2× rows. They're planning figures: your actual pace is yours.