"Extract text from a scanned PDF" sounds like one task, but it's actually five different goals depending on what you want to do with the result. The right workflow depends on whether you need clean prose, structured tables, layout fidelity, the original PDF preserved alongside, or something else entirely. This post walks through five concrete workflows and when each fits.
Workflow 1: Quick Plain Text
Goal: grep a document, count words, paste into an email.
Tradeoff: layout collapses. Columns merge, table cells run together, headers blur into body text.
How: run OCR, save the recognized text directly. On Linux this is pdftotext input.pdf output.txt. Online tools that offer a "text" download give you the same thing. The output is one long stream you can search and process programmatically.
Workflow 2: Layout-Preserving Text
Goal: keep the visual structure — columns, tables, indentation — in plain text.
Tradeoff: the output uses spaces to approximate the original positioning. Wider than 80 characters per line. Diff-able and pipeable, but not pretty.
How: on Linux, pdftotext -layout input.pdf output.txt. The -layout flag positions each word using padding spaces so columns and tables stay aligned. Most online OCR tools don't expose this — but our converter does: after conversion, click "Show Text" in the jobs panel to view it inline or download it as .txt.
Workflow 3: Searchable PDF (Original Layout Preserved)
Goal: keep the document looking exactly the same, but make it searchable and copy-pasteable.
Tradeoff: the output is a PDF, not raw text. To process it programmatically you still need a second extraction step.
How: OCR with the "searchable PDF" output option. The tool runs recognition over each page and embeds an invisible text layer over the original images. Visual rendering is identical to the original; Ctrl-F now works.
This is the most common goal — the user sees the same document but can now search and select text. It's also what archives and libraries usually want: an exact visual replica that's machine-indexable.
Workflow 4: Both PDF and Text
Goal: a searchable PDF for archival and a clean text file for processing — from one upload.
Tradeoff: two output files instead of one. Storage is roughly 1.05x the input PDF for the searchable version, plus a few KB for the text.
How: OCR once, emit two outputs. After OCR produces the searchable PDF, run the layout-preserving extraction on that PDF as a second step. You get exact-layout PDF for archival plus plain text for downstream processing — and they stay consistent because both came from the same recognition pass.
This is what convert2searchablepdf does by default. One upload, both files come back: document_spdf.pdf and document_spdf.txt.
Workflow 5: Structured Extraction (Tables, Forms)
Goal: pull invoice line items, extract form fields, build a CSV from a table-heavy PDF.
Tradeoff: generic OCR isn't enough. You need layout-aware document understanding — services like AWS Textract's table API, Google Document AI's form parser, or specialized invoice extractors.
How: these services accept a PDF and return structured JSON: cells with row/column coordinates, key/value pairs from forms. They're more expensive than plain OCR but save the manual cleanup. For occasional one-off tables, the plain-text layout extraction (workflow 2) plus a quick spreadsheet cleanup is often faster than wiring up a structured extractor.
Picking the Right One
- If you're archiving, use workflow 3 or 4. The PDF stays visually identical and you preserve the option to re-extract later.
- If you're ingesting into a database, use workflow 4 (PDF + text). Index the text, store the PDF for human review.
- If you're searching one document right now, use workflow 1 or 3 — whichever is faster to set up.
- If you're extracting form fields, skip generic OCR; use a structured-extraction service.
Common Gotchas
Encoded text vs scanned image
Some PDFs look scanned but actually have proper text embedded — they were generated digitally and never touched a scanner. For those, you don't need OCR at all; the text is already extractable. Try copying a paragraph first; if it pastes cleanly, OCR is unnecessary.
Mixed pages
Common in legal and bureaucratic documents: some pages are digital text, some are scanned attachments. OCR'ing the whole document is wasteful but harmless — the digital pages just get an additional invisible text layer that matches what was already there. Some tools detect this and skip the digital pages for speed.
Multi-language documents
A document with sections in different languages needs an OCR engine that auto-detects per region rather than processing the whole document as one language. If your output has runs of garbled characters in one section while the rest reads correctly, the engine got stuck on its primary-language guess.
One Practical Recommendation
For most users, workflow 4 (PDF + text in one pass) is the cleanest default. You get the visually-faithful searchable PDF for archival or sharing, and a layout-preserving plain-text version for grep, copy-paste, or downstream processing — without the recognition cost of running OCR twice.
Try it with your own document on the homepage — drop a PDF or image and you get both files back.