A colleague sends an 80-page PDF and you only need the text from a few pages. You copy it, and what lands in your document is either a row of empty boxes or every line chopped in half. The problem is rarely the copy action. It is whether the file contains text at all, and how that text was stored. This article explains that first, then walks through a workflow that runs entirely in your browser.
What "text" actually means inside a PDF
PDF is a page description format. It records where each glyph should be drawn on the page, not that "this is a paragraph". Inside a page content stream, a line of text looks roughly like this:
BT
/F1 11 Tf
72 700 Td
[(Inv)-20(oice)] TJ
0 -14 Td
(Total: 1,280.00) Tj
ETTf selects a font and size, Td moves to the coordinate (72, 700), and TJ and Tj paint strings; the -20 in the array is a kerning adjustment. There is no notion of paragraph, heading or table. Every bit of structure has to be guessed by software from coordinates and font sizes. That one fact explains almost every extraction problem: columns get scrambled because stream order is not reading order, and a word gets split because a kerning adjustment cut it into fragments.
For the purpose of extraction, PDFs fall into three groups. Text-based PDFs, produced by Word, LaTeX or a browser print dialog, carry character codes behind each glyph and can be read directly. Pure scans are one image per page with no text information at all, so only OCR can help. Searchable scans sit in between: an invisible OCR text layer is stacked on top of the image, so search works, but the text is only as good as that earlier recognition pass, and its mistakes are extracted faithfully.
A 30-second test: which kind do you have?
- Drag-select a line of body text in your viewer. If the line highlights, there is a text layer. If you only get a rectangle around a block, it is an image.
- Press Ctrl/Cmd+F and search for a word you can see on the page. No hit, despite the word being visible, points to a pure scan or a broken font encoding.
- Paste a short copied passage into a plain text editor. Normal text is a good sign. Boxes, question marks or strings like (cid:12) mean the font lacks a Unicode mapping, so the text layer exists but cannot be trusted.
- Compare file size to page count. A 30-page text report is often a few hundred KB to a few MB, while a scan of the same length is usually several times larger. That is a hint, not a verdict.
| Type | Typical source | Direct extraction? | Recommended approach |
|---|---|---|---|
| Text-based | Word, LaTeX, web export | Yes, and most accurate | Extract directly, then check reading order |
| Pure scan | Scanner, phone photo | No, the page is one image | Local OCR, then proofread |
| Searchable scan | Scanned then OCR-processed | Yes, but inherits old OCR errors | Extract and spot-check; re-OCR if errors are many |
| Garbled | Old files with missing font mappings | Extracts, but wrong content | Render to images and OCR to bypass the bad encoding |
Extracting locally with ToolGarden: the steps
ToolGarden does not have a dedicated "export TXT" button today. The entry point for text is PDF to Word: it reads the PDF and builds a DOCX, from which you copy the text or save a plain-text version. The upside is that paragraphs, font sizes and images survive for later editing. Here is the flow.
- If the PDF is large and you only want a few pages, first run PDF Extract Pages with a selection such as 3,5-8 and save the smaller file. Fewer pages means faster conversion and OCR, and less irrelevant content to check.
- Open PDF to Word and choose the file. The current code caps a single PDF at 80 MB and the page shows an error beyond that.
- If the file contains scanned pages, set the scanned-page language (English, Simplified Chinese, Traditional Chinese or Japanese). A wrong language is the number one cause of heavily garbled OCR.
- Start the conversion. The tool analyses page by page: pages with a reliable text layer use native extraction; only pages without one load the local OCR model; pages that suit neither fall back to a visual representation (the content is kept as a page image).
- When it finishes, read the smart-routing summary showing how many pages went native, OCR or visual fallback. This line is your best indicator of how far to trust the result.
- Download the DOCX, select all in Word and copy, or save as plain text, then move on to proofreading.
How the tool decides whether a page has a text layer
In the current implementation, a page with at least 24 non-whitespace characters counts as having a reliable text layer. Below that, it looks at the number of text fragments (three or more), or at whether a few characters cover a meaningful share of the page. The point is to avoid a classic trap: a scan that still carries one hidden page number would be classed as text-based if the test were simply "is there any text", and you would extract a single digit. Knowing the rule also explains oddities, such as a cover page with only a few words being sent through OCR.
A worked example: one two-column paper page
Take a two-column English paper. The left column ends with "...the results are summarised in Table 2." and the right column begins "3. Methods". Selecting and copying in a viewer often interleaves lines from the two columns:
the results are summarised in 3. Methods
Table 2. The corpus was divided into
We evaluate three baselines ...The text blocks of both columns are emitted in the content stream interleaved by coordinate. Native extraction groups fragments that share a horizontal line into one line, which is fine for single-column pages but breaks when two unrelated runs of text sit on the same line. Three practical remedies: crop the page into left and right halves and process each; reorganise by column in Word; or export that page as an image and OCR it, because OCR recognises layout blocks and tends to follow the order a human reads.
Here is a line-break example. Printed papers hyphenate words at line ends, and extraction yields:
inter-
national standards require that
the docu-
ment be archived.That hyphen is a soft hyphen inserted by the typesetter, not part of the word. In Word or any editor, use find and replace to remove "hyphen plus line break" and turn lone line breaks into spaces. Check the match count first so you do not damage real compounds such as "state-of-the-art". Ligatures are another classic: fi and fl may come out as single ligature characters, which makes a search for "file" fail. Replace them with the two plain letters.
Scans: how local OCR behaves and what to proofread
For scanned pages the tool first renders the page to an image and then recognises it. In the current implementation the render scale is 2x, with a cap of roughly 12 million pixels per page to protect memory. That is plenty for a normal A4 scan, but it also means recognition quality is bounded by the source: the tool cannot make a blurry 100 dpi scan sharp.
| Factor | Effect on recognition | What you can do |
|---|---|---|
| Wrong language | Heavy garbling, especially on mixed text | Pick the dominant language of the page |
| Low scan resolution | Small text and thin strokes vanish | Rescan; around 300 dpi is a common target for text |
| Skew or shadows | Lines cut off or skipped | Retake, or rotate and crop first |
| Tables and formulas | Structure lost, numbers misaligned | Crop tables separately and retype or rebuild |
| Handwriting | Accuracy drops sharply | Do not expect full accuracy; check every word |
A low-effort proofreading trick: pull out the content where one wrong character matters, such as numbers, names and amounts, and compare it against the page image, then only spot-check the body text. The classic number confusions are 0 versus O, 1 versus l, and 5 versus S, so check every date and amount.
Privacy: why local extraction suits sensitive documents
Contracts, medical records and financial statements are risky to send to an unfamiliar server, even if the operator promises not to keep them. The PDF to Word page states that files are not uploaded and that processing happens in your browser. You do not have to take that on faith: open the Network panel in your developer tools, convert a file, and look for any request carrying your document. One nuance: the first time OCR runs, the browser may fetch static recognition-model assets. That is the model, not your document, and request size and type make the difference obvious.
Diagnosis checklist for common problems
| Symptom | Most likely cause | Fix |
|---|---|---|
| Boxes or (cid:N) when copied | Font lacks a Unicode mapping | Export to images and OCR |
| A space between every letter | Kerning read as spaces, or very wide tracking | Bulk-remove extra spaces in an editor, then recheck word boundaries |
| Nothing extracted at all | The page is an image | Choose the right language and use the OCR path |
| Text in the wrong order | Columns, text boxes, floating captions | Crop by column or reorder by hand |
| Duplicated content | Headers, footers or watermark text extracted too | Strip with find and replace, or remove the watermark first |
| Conversion fails midway | Encrypted, damaged or over the size limit | Remove the open password first; re-save a damaged file from a viewer |
When not to use this approach
- You need evidence-grade, character-exact output. OCR and layout inference both make mistakes, so treat the result as a search and drafting aid and keep the original as the source of truth.
- You are pulling large amounts of structured tabular data. PDF stores no table structure, so converted tables need manual repair. If volume is high, ask the data owner for the original CSV or Excel file.
- You need to preserve the exact layout for repeated printing. Keep the PDF; do not round-trip through Word.
- The file is copyrighted or confidential and conversion is forbidden. Confirm authorisation first.
- You have hundreds or thousands of files. Browser memory is limited; a command-line tool such as poppler pdftotext with its layout option is a better fit.
One habit worth adopting: after each extraction, run the result through Word Count and compare it to a rough estimate for the original pages. A big gap usually means a missing page, a missing column or a failed OCR pass, and you will spot it faster than by reading line by line.