https://txtfetch.com/languages/spanish/
Extract text from Spanish documents, accents intact.
A Spanish PDF, contract, or web page is usually plain Unicode text already. The real risk is a legacy encoding or a normalization mismatch, not the accents themselves.
Español · Latin, with diacritics
what-already-works
Most Spanish documents are born digital. A Word contract, a government PDF, or an HTML page store their words as Unicode text, not as pictures. Tika reads that text layer directly. It keeps á, é, í, ó, ú, ñ, ¿, and ¡ exactly as written, because each one has a single fixed Unicode code point.
character-encodings
| encoding | seen in | note |
|---|---|---|
Windows-1252 (CP1252) | Older Word and Excel files, and email exported from legacy Windows systems. | Fits Spanish's accented letters and ñ into a single byte each. Read as UTF-8 by mistake, each one turns into a two-character garble. |
ISO-8859-1 (Latin-1) | Older web pages and plain-text files that predate UTF-8. | Close to Windows-1252, but not identical. A handful of punctuation marks sit in different byte positions, so a wrong guess still corrupts the text. |
common-pitfalls
- Accented letters turn into pairs of odd characters, like é in place of é.
- The file's real bytes were Windows-1252 or Latin-1, and something read them as UTF-8 instead. This is mojibake. The fix is to read the file with its real encoding, not a guessed one. Fix garbled text from the wrong encoding →
- A search for 'año' finds nothing, even though the page clearly shows the word.
- One copy of the text stores ñ as a single precomposed character (NFC). Another stores it as n plus a separate combining tilde (NFD). The two strings differ byte for byte. Normalize both the extracted text and the search query to NFC before comparing them. What character encoding controls →
- ¿ or ¡ goes missing from the start of a question or an exclamation.
- Some fonts subset their character set to save space and drop the inverted marks entirely. This is a font or PDF production issue, not something extraction can add back. Check the source document. Fix ligatures and smart punctuation →
chunking-and-tokens
Spanish sentences use spaces between words, the same as English. A word-count chunker splits them in the right places. Diacritics don't change that count. The chunk previewer's ~4-characters-per-token estimate holds up well for Spanish, better than it does for a script with no spaces at all.
ocr-status
A scanned Spanish 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. Plain accented letters usually read fine, since each is one Unicode code point, but misreads climb on stylized fonts or low-resolution scans. For a scan where accuracy matters, request quality=premium, which routes a vision-language model instead of Tika. txtfetch publishes no accuracy figure for Spanish 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 Spanish document?
- Yes, but the standard OCR tier ships English trained data only (TESSDATA_LANGS=eng osd). It handles plain accented Latin letters reasonably. For a scan where accuracy matters, request quality=premium, the documented route to a vision-language model instead of Tika.
- Why does my extracted Spanish text show é instead of é?
- The source file used Windows-1252 or Latin-1 bytes, and something downstream assumed UTF-8. Re-read the file with its correct encoding to fix it.
- Why doesn't a search for an accented word match text that visibly contains it?
- NFC and NFD store the same accented letter as different byte sequences. Normalize both the extracted text and your search query to NFC first.
related-reading
Check your Spanish scan first.
The free scan check tells you if a page needs OCR. It runs in your browser.
Check a scan →