What Actually Happens Inside a PDF When You Convert It

You convert a PDF, the file downloads, and something is wrong. The table has collapsed into a run of numbers. The chart has vanished. The document you opened in Word has every word in the right order and none of them in the right place. Nothing reported an error, so there is nothing to look up.

The explanation is a single fact about the format, and once you have it the rest follows: a PDF does not store a document. It stores instructions for drawing one. Every conversion is an attempt to recover something the file was never designed to hold.

A page is a set of drawing instructions

When a word processor saves a file, it records structure. This is a heading. This paragraph contains this sentence. This table has four columns. The appearance is calculated later, when something displays it.

PDF works the other way round. It was designed in 1993 to make a page look identical on every printer and screen, which it achieves by recording appearance and discarding everything else. A page is a stream of operators: set this font, move to these coordinates, draw this glyph, move here, stroke a line of this width. The result is exact. It is also, from a software point of view, a picture assembled from parts rather than a document.

Those parts fall into four kinds, and each one behaves completely differently when you convert it. This is the whole of the problem in one diagram.

Extracting text is reconstruction, not reading

The first surprise for most people is that a PDF often contains no spaces. A converter reading the operators sees a glyph at x=72, another at x=79, then a jump to x=104 before the next one. Whether that jump is a space, the gap between columns, or simply loose letter spacing is not recorded anywhere. The extractor guesses from the size of the gap.

It guesses well on ordinary prose, which is why a converted report reads correctly. It guesses badly on anything arranged in space. A two-column layout reads as one column interleaved with another unless the extractor detects the column boundary. A table has no table: the ruled lines are unrelated vector instructions, and the cells are just glyphs at coordinates. Narrow columns, cells that wrap onto two lines, and right-aligned numbers all push the guess further from what you see.

This is worth knowing before you convert rather than after, because it tells you what to check. Run your file through the PDF to text converter and read the tables first. If they survived, the rest almost certainly did.

The scanned document problem

There is a second case where extraction does not guess badly but returns nothing at all, and it accounts for most reports of a converter "not working".

A scanned PDF has no text layer. A scanner produces an image, wraps it in a PDF container, and the result looks exactly like a document on screen while containing no characters whatsoever. Ask a converter for the text and it correctly reports that there is none. The output is empty, no error appears, and the file looked fine.

Two questions settle which kind you have, and you can answer both in your PDF reader before converting anything.

If the answer is a scan, no converter will help, because the operation you need is not conversion. Optical character recognition looks at the pixels and decides which letters they depict, which is a recognition problem with an error rate rather than a format translation. Our image to text tool runs OCR in the browser; for a multi-page scan, export the pages with PDF to JPG first.

What each conversion actually keeps

Because the four layers survive differently, there is no conversion that keeps everything, and choosing one means choosing what to lose.

Converting to an image keeps the appearance perfectly and discards every machine-readable property. The text stops being text. The vectors stop being scalable. What you get is exactly what the page looked like at the resolution you chose, which is the right answer when you need a thumbnail, a preview, or a page to place in a design. Both PDF to JPG and PDF to PNG render each page separately and deliver a multi-page document as a numbered set.

Converting to text or Word does the opposite. It keeps the words and abandons the drawing: charts disappear entirely, because a chart is vector instructions and vector instructions contain no characters. Layout arrives approximately, reconstructed from coordinates. Use PDF to Word when the words are the point and the design is not.

Converting to SVG is the case that surprises people who know the formats, because both are vector formats and the conversion looks like it should be lossless. The data really is there: a PDF page holds genuine drawing instructions that could become SVG paths. What is missing is a reliable way to separate them, in a browser, from the text and photographs they are stacked with. Every practical converter, ours included, renders the page at high resolution and places that image inside a valid SVG file. It scales and opens anywhere, and the shapes are not editable. We say so on the PDF to SVG page rather than letting the format names imply otherwise. If you need editable vectors, open the PDF in Illustrator or Inkscape, which read its operators directly.

Why the output is sometimes larger than the input

A PDF shares resources. A font used across two hundred pages is embedded once. A logo repeated in every header is stored once and referenced two hundred times. Text compresses well, and the format compresses it.

Converting to images destroys all of that. Each page becomes an independent picture carrying its own copy of everything drawn on it, rendered at whatever resolution you picked. A twenty-page document of a few hundred kilobytes routinely becomes twenty images several times larger in total. The same effect shows up when merging: combining two PDFs that each embed the same font can produce a file larger than the sum of its parts, because the shared resource is now stored twice. Merging followed by compression usually recovers it.

Choose the conversion by what you need to keep

Decide first which layer matters, and the conversion follows without any guesswork:

• The words, for editing — text or Word, and only if the file has a text layer.
• The appearance, exactly — an image, at the highest resolution you can live with.
• The words from a scan — OCR, not conversion.
• Specific pages — split or remove pages and stay in PDF, which loses nothing at all.
• A smaller file — compress rather than convert; the format is already efficient.

The conversions that lose the least are the ones that stay inside PDF. Rotating, splitting, merging and deleting pages rearrange the existing objects without redrawing anything, so text stays text and vectors stay vectors. If your goal can be met without leaving the format, that is always the better route.

A note on where this happens

Everything described here runs in your browser. The file is read from your disk into memory, parsed and transformed on your own processor, and written back out. It is never uploaded, queued on a server, or retained anywhere, which matters more for PDFs than for most formats: the documents people convert are contracts, medical records, bank statements and manuscripts. The security argument for client-side conversion goes through what a cloud converter does with your upload instead.