https://txtfetch.com/languages/portuguese/
Extract text from Portuguese documents, either variety.
Brazilian and European Portuguese are the same language stored as the same Unicode text. The real risks are a legacy encoding and a normalization mismatch on ã, õ, and ç.
Português · Latin, with diacritics
what-already-works
Most Portuguese documents are born digital, whether written in Brazil or Portugal. Tika reads the Unicode text layer of a Word file, PDF, or web page directly. ã, õ, ç, á, and â are each a single fixed code point, kept 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 Portuguese's accented letters and ç into a single byte each. Read as UTF-8 by mistake, each one garbles into two characters. |
ISO-8859-1 (Latin-1) | Older web pages and plain-text files that predate UTF-8. | Close to Windows-1252 but not identical in byte layout, so a wrong guess still corrupts the text. |
common-pitfalls
- ã, õ, ç, or â turns into a garbled two-character sequence.
- The file's real bytes were Windows-1252 or Latin-1, and something read them as UTF-8. This is mojibake. Read the file with its real encoding instead of a guessed one. Fix garbled text from the wrong encoding →
- A search for 'não' or 'informação' misses text that visibly contains it.
- One copy stores each accented letter as a single precomposed character (NFC). The other stores it as a base letter plus a separate combining mark (NFD). The strings differ byte for byte. Normalize both the extracted text and the search query to NFC before comparing them. What character encoding controls →
- Brazilian spelling ('fato') and European spelling ('facto') for the same word don't match in a keyword search.
- The two are not spelling errors. They are the same language written under two different national orthographies. Search both spellings, or normalize known variant pairs yourself. txtfetch extracts text as written and does not localize spelling.
chunking-and-tokens
Portuguese sentences use spaces between words, so a word-count chunker splits them in the right places. Diacritics don't change that count, whether written in Brazil or Portugal. The chunk previewer's ~4-characters-per-token estimate holds up well for Portuguese.
ocr-status
A scanned Portuguese document still needs OCR, and Tesseract still reads the Latin alphabet underneath. But the standard OCR tier ships English trained data plus script detection only (TESSDATA_LANGS=eng osd), tuned for English letter shapes. Accented letters usually read fine on a clean scan, but misreads climb on low resolution or stylized fonts. For a scan where accuracy matters, request quality=premium, which routes a vision-language model instead of Tika. No accuracy figure is published for Portuguese 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.
- Does txtfetch tell Brazilian and European Portuguese apart?
- No. txtfetch extracts the text exactly as written, in either spelling variant, and doesn't tag which one it is.
- Can txtfetch OCR a scanned Portuguese document?
- Yes, but the standard OCR tier ships English trained data only (TESSDATA_LANGS=eng osd). For a scan where accuracy matters, request quality=premium.
- Why doesn't a search for 'informação' match text that clearly shows the word?
- NFC and NFD store the same accented letter as different byte sequences. Normalize the extracted text and your search query to NFC first.
related-reading
Check your Portuguese scan first.
The free scan check tells you if a page needs OCR. It runs in your browser.
Check a scan →