Extract text from Korean documents, Hangul intact.

한국어 · Hangul, with occasional Hanja

what-already-works

A born-digital Korean file, a Word document or a modern PDF with a real text layer, needs no OCR. Tika reads its Unicode text layer directly. Occasional Hanja, Chinese-derived characters used in formal or legal Korean writing, are read the same way as any other Unicode text.

character-encodings

common-pitfalls

Hangul turns into an unrelated string of symbols.

EUC-KR or CP949 bytes read as UTF-8, or the reverse. This is mojibake from a legacy Korean encoding. Re-read the file with its real encoding. Fix garbled text from the wrong encoding →

The same Korean word, spelled the same way, fails to match itself in a search index.

One copy stores each syllable as a single precomposed Hangul block. The other stores it as separate jamo, the individual consonant and vowel letters, which render the same way but differ byte for byte. Normalize Hangul jamo sequences to precomposed NFC form before comparing or indexing. What character encoding controls →

Chunk sizes look reasonable for Korean, but real token counts run higher than the character-based estimate predicts.

Korean spaces separate phrases, not always single dictionary words, so a word-count chunker undercounts real segment density, and each Hangul block carries more information than one Latin letter. Treat the chunk previewer's character-based estimate as a floor for Korean text, not an exact count. What chunking actually does →

chunking-and-tokens

Korean text does use spaces, unlike Japanese or Chinese, so a word-count chunker isn't completely blind to it. But those spaces mark phrases, not always single words, and each Hangul block packs more meaning than a Latin letter. The chunk previewer's ~4-characters-per-token estimate still runs low for Korean, just less severely than it does for Japanese or Chinese.

ocr-status

A scanned or photographed Korean 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, but it can't read Hangul, since that needs Korean-trained OCR data the standard tier doesn't ship. For a scanned Korean document, request quality=premium, which routes a vision-language model instead of Tika. No accuracy figure is published for Korean OCR under either tier. If scanned Korean 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 Korean 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 Korean scan.

Does Korean text need special chunking, since it has spaces?

Korean spaces mark phrases, not always single words, and each Hangul block carries more meaning than one Latin letter. The character-based token estimate still runs a bit low for Korean.

Why does a Korean word fail to match itself in a search index?

One copy likely stores Hangul as precomposed syllable blocks, the other as separate jamo letters. Normalize both to NFC before comparing.

related-reading

• What comes back: text, Markdown, or JSON →
• Chunk previewer →
• Glossary: character encoding →
• Contact →
• Get an API key →