> Source: https://txtfetch.com/languages/chinese
> Plain-text twin — every page on txtfetch.com has one. https://txtfetch.com/text

---

# Extract text from Chinese documents, either character set.

A born-digital Chinese file needs no OCR, Simplified or Traditional. A scanned one hits the same real limit as Japanese: the standard OCR tier can't read Han glyphs.

中文 · Han, Simplified and Traditional

what-already-works

A born-digital Chinese file, a Word document or a modern PDF with a real text layer, needs no OCR. Tika reads its Unicode text layer directly, whether the document uses Simplified or Traditional characters. Each Han character is its own fixed Unicode code point.

character-encodings

| encoding | seen in | note |
| --- | --- | --- |
| `GB2312` | Early Simplified Chinese systems and some legacy exports. | Covers a limited set of common Simplified characters. A rarer character outside that set can't be represented at all. |
| `GBK` | A wider successor to GB2312, still found in older Windows software. | Extends GB2312's character coverage but keeps the same two-byte structure, so it isn't interchangeable with UTF-8 or Big5. |
| `GB18030` | The mandated national standard for Simplified Chinese text in China today. | Covers the full Unicode range, unlike GB2312 or GBK, but still uses byte sequences different from UTF-8 for the same characters. |
| `Big5` | Traditional Chinese systems, mainly in Taiwan and Hong Kong. | A separate two-byte scheme from the GB family. A Big5 file read as GBK garbles just as badly as one read as UTF-8. |

common-pitfalls

**Chinese characters turn into unrelated symbols or boxes.**: GB2312, GBK, GB18030, or Big5 bytes read under the wrong encoding, including UTF-8. This is mojibake from a legacy Chinese encoding. Re-read the file with its real encoding. Fix garbled text from the wrong encoding →

**A word-count chunk size is meaningless for Chinese text.**: Chinese writing has no spaces between words, the same underlying issue as Japanese. Chunk Chinese text by character or token count instead of by word count. What chunking actually does →

**A search for a Simplified Chinese term finds nothing in a Traditional Chinese document, or the reverse.**: Simplified and Traditional Chinese use different character forms for many common words. They are different character sets, not encoding variants of each other. Search both forms, or convert one to the other with a known Simplified-Traditional mapping before matching.

chunking-and-tokens

Chinese has no spaces between words, so a word-count chunker cannot split it at all, Simplified or Traditional. Each character carries more meaning than a Latin letter does. The chunk previewer's ~4-characters-per-token estimate badly understates the real token count for Chinese text.

ocr-status

A scanned or photographed Chinese document is a different problem than a born-digital one. The standard OCR tier ships English trained data plus script detection only (TESSDATA\_LANGS=eng osd). It can tell a page isn't Latin script. It can't turn Han characters into text, since that needs Chinese-trained OCR data the standard tier doesn't ship. For a scanned Chinese document, request quality=premium, which routes a vision-language model instead of Tika. No accuracy figure is published for Chinese OCR under either tier. If scanned Chinese is a large part of your workload, contact us before you commit to a plan.

faq

**Does txtfetch detect or label the document's language?**: No. txtfetch extracts the text as written and hands it back as-is. It does not detect, tag, or translate a document's language. There is no language parameter to set.

**Can txtfetch OCR a scanned Chinese document?**: Not reliably with the standard tier, which ships English trained data plus script detection only (TESSDATA_LANGS=eng osd). Request quality=premium for the documented route to reading a Chinese scan.

**Does txtfetch convert between Simplified and Traditional Chinese?**: No. txtfetch extracts the text exactly as written in the source document, Simplified or Traditional, and does not convert between them.

**Why is my word-count chunk size wrong for Chinese text?**: Chinese has no spaces between words, so a word-count chunker can't split it correctly. Chunk by character or token count instead.

related-reading

-   [What comes back: text, Markdown, or JSON →](https://txtfetch.com/output)
-   [Chunk previewer →](https://txtfetch.com/tools/chunk-preview)
-   [Glossary: token →](https://txtfetch.com/glossary/token)
-   [Contact →](https://txtfetch.com/contact)
-   [Get an API key →](https://app.txtfetch.com/signup)

other-languages

-   [Spanish →](https://txtfetch.com/languages/spanish)
-   [French →](https://txtfetch.com/languages/french)
-   [German →](https://txtfetch.com/languages/german)
-   [Portuguese →](https://txtfetch.com/languages/portuguese)
-   [Japanese →](https://txtfetch.com/languages/japanese)
-   [Korean →](https://txtfetch.com/languages/korean)
-   [Arabic →](https://txtfetch.com/languages/arabic)
-   [Russian →](https://txtfetch.com/languages/russian)
-   [All languages →](https://txtfetch.com/languages)

## Check your Chinese scan first.

The free scan check tells you if a page needs OCR. It runs in your browser.

[Check a scan →](https://txtfetch.com/tools/image-ocr-check)

[Get an API key →](https://app.txtfetch.com/signup)