When a PDF displays perfectly but extracted text is broken, it is tempting to assume the converter failed to “read the words.” The deeper problem is that the file may never have stored words in a semantic form. PDF is a page-description format: it preserves appearance by drawing glyphs at positions, often with custom font encodings and no declared paragraph structure.
Understanding the main failure modes makes troubleshooting faster and prevents endless retries with tools that use the same underlying text layer.
Characters are not always Unicode text
A font maps character codes to visible glyphs. In a well-formed PDF, a ToUnicode map explains which Unicode character each glyph represents. Extraction can then turn the displayed shapes back into searchable text.
Some PDFs omit or damage that map. The viewer still draws the right shapes because it has the embedded font, but extraction returns unrelated letters, boxes, or empty strings. Subset fonts complicate the picture by renaming fonts and including only the glyphs used in the document.
Copy one sentence from the PDF viewer into a plain-text editor. If it is already garbled, a simple text-layer converter will likely produce the same result. OCR can sometimes recover the visible characters by treating the page as an image, but it introduces recognition errors and needs validation.
Spaces may be inferred rather than stored
PDF content streams can position each word separately without a space character. The visual gap tells a reader where the space belongs. An extractor estimates spaces from coordinates, font size, and text width.
If the threshold is too small, words merge. If it is too large, spaces appear inside words. Justified text, kerning, unusual fonts, and transformed coordinates make one threshold unreliable across a page.
This also affects columns. A large gutter should separate text regions, not create a string with many spaces. Layout-aware parsing needs to distinguish word gaps, cell gaps, and column gaps.
Lines and paragraphs are visual constructs
A PDF may contain one text object per character, word, line, or entire paragraph. It can draw the second half of a sentence before the first and still display correctly because coordinates determine final placement. The storage sequence is not guaranteed to match reading order.
Extractors usually group items by vertical position to form lines, sort them horizontally, and then compare vertical gaps to form paragraphs. This works for simple pages but struggles with superscripts, drop caps, sidebars, rotated labels, and mixed font sizes.
Paragraph breaks are especially ambiguous. A larger gap can mean a new paragraph, a heading, or simply a page-layout adjustment. Indentation can mean a list, quotation, code block, or decorative alignment.
Multi-column pages create competing order
On a two-column page, both columns contain lines at the same vertical positions. Sorting by row interleaves them. Sorting all items by horizontal position can concatenate entire columns incorrectly when full-width headings are present.
A deterministic parser can detect stable gutters and process each region. Complex publications need region detection because figures, captions, and titles can span columns. The multi-column guide gives a practical workflow.
The important point is that correct characters do not guarantee correct prose. Reading order is an inferred layer.
Hyphenation crosses layout and language
Typeset documents split words at line endings. Extraction preserves the visible hyphen, but Markdown usually wants the full word. Removing every line-end hyphen is unsafe because some are genuine compounds or minus signs.
Language dictionaries, word frequency, and source comparison can guide dehyphenation. Names, chemical terms, and code identifiers remain difficult. Automated cleanup should record uncertain replacements or be reviewed on representative pages.
Soft hyphens and different Unicode dash characters can also create search mismatches even when the text looks normal.
Tables have geometry but little cell meaning
Some PDFs draw tables as text aligned over lines. Others use tagged structures, but support varies. Without cells, extraction has to infer rows and columns from coordinates. Wrapped values, empty cells, merged headers, and cross-page continuation break simple grouping.
Flattening the text can be worse than admitting that the table needs separate handling. Choose Markdown, CSV, or HTML based on the structure and validate critical values. See the PDF table guide for concrete checks.
Scans contain pixels, not glyphs
An image-only PDF may contain no extractable text. OCR predicts characters from pixels and may also predict layout. Resolution, skew, noise, handwriting, language, and typography affect recognition.
Some scanned PDFs contain a hidden OCR layer. Copy-paste works, but errors in that layer flow directly into Markdown. Compare names, dates, numbers, and punctuation with the visible image.
Use the text versus scanned PDF guide to classify files before choosing a converter.
Tagged PDF helps but is not universal
Accessible tagged PDFs can describe headings, paragraphs, lists, tables, and reading order. When tags are accurate, they provide better semantics than visual heuristics. Many documents are untagged, partially tagged, or tagged incorrectly, and parsers vary in how much of that structure they use.
Do not assume that a file passing visual review has good tags. Conversely, do not discard useful tags by flattening everything to coordinates when a tool can preserve them.
Troubleshoot by isolating the layer
First test copy-paste. Garbled characters indicate encoding; empty output suggests a scan; correct words in wrong sequence indicate layout. Next compare a simple page with a complex one. If only columns or tables fail, route those pages to a layout-aware tool.
Inspect document properties and fonts. Developers can use local utilities such as pdffonts and pdftotext to distinguish encoding and parser behavior. Test OCR only when the visible page is clearer than the text layer.
Finally, define what must be preserved. For search notes, readable prose may be enough. For financial tables or equations, structural fidelity is essential. No converter can recover semantics that the page does not reveal; the reliable workflow combines the right extractor with explicit review.
