https://txtfetch.com/languages/french/
Extract text from French documents, œ and all.
French text is plain Unicode once it's born digital. The failure modes are a dropped ligature, a legacy encoding, or a typographic apostrophe the extractor misreads.
Français · Latin, with ligatures and diacritics
what-already-works
A born-digital French file, a Word document, a PDF with a real text layer, or an HTML page, needs no OCR at all. Tika reads its Unicode text layer directly. é, à, ç, and the œ ligature are each their own fixed code point, so the script itself isn't the hard part.
character-encodings
| encoding | seen in | note |
|---|---|---|
Windows-1252 (CP1252) | Older Word and Excel files, and email exported from legacy Windows systems. | Covers é, à, ç, and œ in a single byte each. Read as UTF-8 by mistake, every one of them garbles. |
ISO-8859-1 (Latin-1) | Older web pages and plain-text files that predate UTF-8. | Does not include œ at all. A file in this encoding often substitutes a placeholder character for it, well before extraction ever sees it. |
common-pitfalls
- œ in a word like cœur or œuvre splits into two separate letters, oe.
- A font or a PDF's internal character map never gave the ligature its own code point, or an editor auto-corrected it before the file was saved. This is a lost ligature, not a bug in extraction. Check the fix for ligatures and smart punctuation. Fix ligatures and smart punctuation →
- The space before a French question mark, colon, or exclamation point has vanished.
- French typography places a narrow non-breaking space before ; : ! ?, and some fonts or PDF producers drop it or substitute an ordinary space during layout. The words themselves are intact and in order. Treat the missing space as a style detail, not a data loss.
- An apostrophe in l'année or c'est renders as a box or a stray, unrelated character.
- The document used a typographic apostrophe (’), and the extractor's encoding guess didn't include it. Confirm the file's real encoding, then re-run extraction with it identified correctly. Fix garbled text from the wrong encoding →
chunking-and-tokens
French uses spaces between words, so a word-count chunker splits French text about as well as it splits English. The œ ligature counts as one visual character. An unfolded copy can carry two code points instead of one, which slightly skews a character-based token estimate. The chunk previewer's ~4-characters-per-token guide still holds up reasonably well overall.
ocr-status
A scanned French document needs OCR, and Tesseract's Latin-alphabet training covers most of French's letterforms. But the standard OCR tier ships English trained data plus script detection only (TESSDATA_LANGS=eng osd). Accented letters and the œ ligature 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 French 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 French document?
- Yes, but the standard OCR tier ships English trained data only (TESSDATA_LANGS=eng osd). Accented letters and the œ ligature are the first things to lose accuracy on a low-resolution scan. Request quality=premium for a hard scan.
- Why does cœur come back as coeur?
- The œ ligature lost its own code point somewhere upstream, usually in the font or the PDF's character map, not during extraction itself. See the ligature fix for the full explanation.
- Why is the space before a French question mark missing?
- French typography uses a narrow non-breaking space there, and some PDF producers drop or substitute it during layout. The words and their order are unaffected.
related-reading
Check your French scan first.
The free scan check tells you if a page needs OCR. It runs in your browser.
Check a scan →