Back to blog
September 7, 20267 min readpdf-conversionguides

PDF Converter: What Every Online Converter Can and Can't Do

Not all PDFs convert equally. Whether a converter succeeds depends on how the file stores its content and what shape that content is in. Here is the capability map, by document type, with the failure mode of each conversion path.

By Saurav Agarwal

A PDF converter's success is decided before you upload anything: by whether the file carries a text layer, and by what shape the content is in. Text-layer prose converts near-perfectly. Scanned pages need OCR and inherit its error rate. Tables are the hardest case in either format, because PDF stores no table structure at all.

Key takeaways

  • PDFs store positioned glyphs, not paragraphs, tables, or columns. Every converter reconstructs that structure by inference.

  • A text-layer PDF and a scanned PDF are different problems. Check which you have before choosing a tool.

  • Prose converts well. Forms convert adequately. Tables — especially financial tables — are where general-purpose converters degrade.

  • No converter is best at everything. Match the tool to the document type.

What is actually inside a PDF file?

A PDF is a page-description format. It records which glyph to draw at which x/y coordinate, in which font, on which page. It does not record that six glyphs form a word, that a run of words forms a paragraph, or that a group of numbers forms a column.

This is the single fact that explains almost every conversion failure. When a converter gives you a Word document with correct paragraphs, or a spreadsheet with correct columns, it did not read that structure out of the file. It inferred it from coordinates, whitespace, and font changes.

Inference works well when the layout is regular and generously spaced. It degrades when columns sit close together, when a cell wraps onto two lines, or when the page has no ruling lines to anchor the guess.

Does my PDF have a text layer or is it a scan?

There are two kinds of PDF, and they fail in completely different ways.

Text-layer (digital) PDFs were generated by software — a bank's statement generator, Word, a browser's print-to-PDF. The glyphs are real characters with real coordinates. Extraction is a geometry problem.

Scanned (image-only) PDFs are photographs of paper. The page is one flat image. There are no characters at all until optical character recognition creates them. Extraction is a geometry problem plus a recognition problem.

Here is a five-second test that needs no software:

  1. Open the PDF in any viewer.

  2. Try to select a line of text with your cursor.

  3. If individual words highlight, you have a text layer. If the whole page highlights as one block, or nothing highlights, it is a scan.

You can also press Ctrl+F (Cmd+F) and search for a word you can see on the page. No match means no text layer.

Which conversions work well, and which don't?

Conversion difficulty is a function of how much structure has to be inferred and how costly a wrong guess is.

Conversion

Difficulty

What usually goes wrong

PDF → Word (prose)

Low

Minor spacing and font substitution; content survives

PDF → text

Low

Reading order scrambles on multi-column layouts

PDF → image

Trivial

Nothing — it is a render, not an extraction

Image → PDF

Trivial

Nothing — the image is embedded as-is

PDF → Word (complex layout)

Medium

Text boxes and floats land in the wrong reading order

PDF → Excel (simple ruled table)

Medium

Usually fine when every cell has visible borders

PDF → Excel (borderless table)

High

Column boundaries guessed from whitespace; wrapped cells split

PDF → Excel (financial table)

High

Merged descriptions, split amounts, lost running balance

Scanned → any format

High

Inherits OCR error rate on every character

The pattern: the more your document depends on spatial relationships to carry meaning, the more a converter can get wrong.

Prose is forgiving. If a converter misjudges a line break, you can still read the paragraph. A table is unforgiving. If a converter puts a number in the wrong column, the document is still readable but the data is now wrong — and wrong in a way that looks perfectly plausible.

Why are tables the hard case?

Because "table" is not a thing a PDF contains. It is a thing a human sees.

To rebuild a table, a converter has to answer four questions with no help from the file:

  1. Where are the column boundaries? With ruling lines, this is easy. Without them — and most bank statements have none — boundaries must be inferred from vertical alignment of text across many rows.

  2. Where does a row start and end? A transaction description that wraps onto a second line looks identical to a second transaction with empty amount fields.

  3. Which cells are empty? A blank in a debit column is meaningful. Whitespace is not stored, so absence must be inferred from position.

  4. Does this table continue on the next page? A repeated header mid-document is a new page, not a new table — but only if the converter knows to look.

A general-purpose converter answers these with generic heuristics because it has to work on invoices, reports, timetables, and menus alike. That generality is a real strength, and it is also why financial tables are where it most often gives ground.

How do I pick the right tool?

Match the tool to the document, not to brand familiarity.

  • Prose, occasional use — any mainstream converter will do. This is a solved problem.

  • Images, merging, compression, signing — general-purpose PDF suites. Breadth is genuinely what you want.

  • Simple ruled tables — general converters usually handle these; check the first and last row.

  • Financial tables, repeatedly — a converter that knows what a transaction row is, because the guesses above are not generic when the document is a bank statement.

That last category is why specialised tools exist. A converter that knows it is looking at a statement can use constraints a general tool cannot: dates advance through the period, a running balance must reconcile against the previous row, and debits and credits are distinct fields rather than a single "amount" column.

If bank statements are your case specifically, the complete guide to converting a bank statement to Excel covers the methods in order, including the free ones.

What should I check on any converted file?

Whatever tool you use, verify before you trust. Three checks catch most errors in under a minute.

  1. Row count. Count transactions on the PDF for one page. Compare to the output. A mismatch means rows were merged or dropped.

  2. First and last row. Extraction errors cluster at boundaries — the first row after a header and the last row before a page break.

  3. Totals. For financial documents, sum the amounts and reconcile against the statement's own closing balance. This is the strongest check available, because it validates every row at once.

The third check matters most. Converted data that looks clean can still be wrong, and only arithmetic catches it.

Frequently asked questions

Are free PDF converters safe to use?

It depends entirely on what the document contains and what the service does with it. For a public brochure, risk is negligible. For a bank statement, tax return, or contract, you are uploading sensitive data to a third party — read the retention policy first and confirm how long files are kept, whether they are used to train models, and how deletion works.

Why does my converted spreadsheet have everything in one column?

The converter could not identify column boundaries, so it treated each line as a single text value. This is typical for borderless tables where columns are separated by whitespace rather than ruling lines. It is a structural failure, not a settings problem, and a different extraction approach is usually needed.

Can a converter recover a PDF that was scanned crookedly?

Partially. Most OCR pipelines deskew the image before recognition, which handles a few degrees of rotation well. Heavy skew, shadows, and low resolution degrade accuracy sharply. Scanning at 300 DPI, flat, in even light is worth more than any post-processing.

Is PDF to Excel more accurate than PDF to CSV?

Neither format is more accurate — accuracy is decided during extraction, before the file is written. The difference is what survives afterwards. CSV holds plain values and is what most accounting software imports. Excel can carry formatting and multiple sheets, which is useful for review but irrelevant to the extraction itself.

Why do two converters give different results on the same PDF?

Because each one guesses differently. Different tools use different strategies for finding column boundaries and grouping rows, so they disagree exactly where the document is ambiguous. Consistent disagreement between tools is a reliable signal that the document is a hard case and the output needs checking.