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

---

# Extract text from German documents, compounds and ß included.

German text is plain Unicode once it's born digital. The real risks are ß folding to ss, a legacy encoding, and compound words that break a word-count chunker.

Deutsch · Latin, with umlauts and ß

what-already-works

A born-digital German file, a Word document, a PDF with a real text layer, or an HTML page, needs no OCR. Tika reads its Unicode text layer directly. ä, ö, ü, and ß are each their own fixed code point, so extraction keeps them exactly as written.

character-encodings

| encoding | seen in | note |
| --- | --- | --- |
| `Windows-1252 (CP1252)` | Older Word and Excel files, and email exported from legacy Windows systems. | Fits ä, ö, ü, and ß into a single byte each. Read as UTF-8 by mistake, every one garbles. |
| `ISO-8859-1 (Latin-1)` | Older web pages and plain-text files that predate UTF-8. | Covers the same German letters as Windows-1252, but not identically laid out, so a wrong guess still corrupts text. |
| `ISO-8859-15 (Latin-9)` | German business documents produced after the late 1990s. | Adds the euro sign € over Latin-1. A file in this encoding read as Latin-1 misreads every € as a different character entirely. |

common-pitfalls

**ß in a word like Straße or groß turns into ss, or into a garbled character.**: Some fonts and encodings fold ß to ss for legacy compatibility, and others misencode the single ß character outright. Both spellings are valid German today, but they are not the same string. Normalize ß consistently across search and comparison.

**A long compound word like Rechtsschutzversicherungsgesellschaften blows past a downstream length limit.**: German freely joins nouns into one unbroken compound word with no internal spaces. A word-count chunker sees a single 'word', but that word alone can run to dozens of characters. Size chunks by character or token count, not by word count, whenever German text is likely. What chunking actually does →

**ö, ü, or ä turns into a boxy replacement character or a two-character garble.**: The source bytes were Windows-1252, Latin-1, or Latin-9, and something read them with the wrong encoding. Confirm the file's real encoding before extraction, the same fix as any other mojibake case. Fix garbled text from the wrong encoding →

chunking-and-tokens

German compounds words without spaces inside them, so a single 'word' can run past 30 characters. A word-count chunker treats that whole compound as one unit and badly misjudges its size. The chunk previewer's ~4-characters-per-token estimate is a better guide for German than a word count. A real tokenizer usually still splits a long compound into several tokens on its own.

ocr-status

A scanned German document needs OCR, and Tesseract's Latin-alphabet training covers most German letterforms. But the standard OCR tier ships English trained data plus script detection only (TESSDATA\_LANGS=eng osd). Umlauts and ß are where accuracy drops fastest on a low-resolution scan. For a scan where accuracy matters, request quality=premium, which routes a vision-language model instead of Tika. No accuracy figure is published for German OCR under either tier.

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 German document?**: Yes, but the standard OCR tier ships English trained data only (TESSDATA_LANGS=eng osd). Umlauts and ß lose accuracy fastest on a low-resolution scan. Request quality=premium for a hard scan.

**Why do German compound words break my chunk sizes?**: German joins nouns into one long word with no internal spaces. A word-count chunker can't see inside it. Chunk by character or token count for German text instead.

**Does txtfetch normalize ß to ss, or the reverse?**: No. txtfetch returns the text exactly as extracted. If your pipeline needs one consistent spelling, normalize ß yourself after extraction.

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)
-   [Idempotency →](https://txtfetch.com/docs/idempotency)
-   [Get an API key →](https://app.txtfetch.com/signup)

other-languages

-   [Spanish →](https://txtfetch.com/languages/spanish)
-   [French →](https://txtfetch.com/languages/french)
-   [Portuguese →](https://txtfetch.com/languages/portuguese)
-   [Japanese →](https://txtfetch.com/languages/japanese)
-   [Chinese →](https://txtfetch.com/languages/chinese)
-   [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 German 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)