What a PDF Really Is

We built the two extremes ourselves. A 602-byte file that tells a viewer where to put each letter, and a 5.9 MB bitmap of the exact same page, look pixel-identical on screen, and only one of them lets a program pull the words back out. Converting a real PDF to PNG and a DOCX to PDF on FileFlip's own engine shows where that line sits, and why it moves depending on what built the file.

What does this mean for the file in front of you?

Check what you're holding before you decide what to do with it.

• You have a real PDF and want an image. Convert PDF to PNG and FileFlip replays the page's own instructions at a fixed 2x scale. Whatever size the page already was, it keeps that size.
• You have a DOCX and want a PDF. Convert DOCX to PDF and the result always lands on a fixed A4 page, 595 by 842 points, no matter what page size the DOCX specified. We measured this below.
• You have a PDF and can't select any text. Nothing is broken. The page is stored as a picture, and no conversion adds words that were never in the file to begin with. See why further down.

PDF, DOCX and PNG at a glance

Is a PDF a picture of a page, or a program that draws one?

A program. Each page is a short list of commands, and the software reading the file runs them, the same way a browser runs the tags in an HTML page.

Here's proof you can read yourself. This is a complete, valid PDF, 602 bytes end to end, that a real PDF viewer opens without complaint:

BT /F1 18 Tf 20 100 Td (Hand-written, 12 lines.) Tj ET

BT starts a text object, /F1 18 Tf picks a font and size, Td positions it, and Tj paints the string. ET closes the block. That's the whole page, and it's what the ISO 32000 specification calls a content stream: operators a viewer executes, not an image it displays.

We rebuilt one real page two ways. FileFlip's own DOCX to PDF route produces 121 KB, still real text a program can read. Storing the same rendered page as a raw, uncompressed bitmap instead, the crudest possible "picture of a page," comes out at 5.9 MB. 49 times bigger, for identical pixels.

Why does a PDF carry its own fonts?

So the page still looks right on a machine that has never heard of the typeface it was written in.

A content stream's Tf operator references a font by name, and that name has to resolve to real glyph data somewhere. Fourteen fonts, Helvetica included, are "standard" fonts every conforming viewer must have built in, which is why our 602-byte file never had to embed one. Anything else travels inside the file itself, and whether it actually does is exactly what an archival format like PDF/A checks before it calls a file valid.

We checked which one FileFlip does. Converting DOCX to PDF, pdffonts reports two embedded fonts in the output, Charis SIL Bold and Charis SIL Regular, both marked emb yes. That's not the font from your Word document, though. The DOCX-to-PDF route goes through an HTML step first, and font styling doesn't survive it, so what you get is mupdf's own built-in serif font, properly embedded, just not the one you typed in.

Why can I select text in some PDFs and not others?

Because some PDFs have a text operator behind every letter, and some only have a picture where the letters used to be.

Take the 121 KB DOCX-to-PDF output above and run pdftotext against it: 68 words come back, including one we planted specifically to check for. Run the identical command against that same page rendered as an image instead. Zero words, because there is no text object anywhere in the file for pdftotext to find.

That middle row is the trap. A properly compressed picture can be smaller than the real text version, so file size alone tells you nothing about which kind of PDF you're holding. The only reliable test is trying to select or search a word, which is exactly the check in why you can't select text in some PDFs. A scanned document is our "picture" row in real life: a photograph of a page, saved as a PDF, with nothing underneath for a computer to read. Converting it to any other format won't recover text that was never there, because there's nothing there to recover.

Why is a PDF's page size fixed?

Because a page only becomes a PDF once something decides its dimensions in points, 1/72 of an inch, and after that the file never asks again.

A real PDF already answered that question when it was made, baked into the page as its /MediaBox. We wrote a page with a deliberately odd size, 300 by 150 points, and converted it with FileFlip's PDF to PNG route. The output PNG came back at exactly 600 by 300 pixels: our worker's render call, toPixmap(Matrix.scale(2, 2), ...), always renders at a fixed 2x, so the page's own geometry survived untouched and only the scale changed.

DOCX never answers that question, since Word text reflows to fit whatever page opens it. FileFlip's document worker has to invent a page for it, and it invents the same one every time: document.layout(595, 842, 11), A4 at 72 points per inch. We set a DOCX file's page explicitly to US Letter, 612 by 792 points, ran it through the real DOCX-to-PDF pipeline, and got 595 by 842 points back, A4, matching neither the DOCX's stated size nor anything we asked for.

What does that make easy to convert, and what does it make hard?

Turning a PDF into an image is easy, because the file already says exactly what to draw and where. Turning it into an editable document is the harder direction, because a content stream stores position, not structure.

A Tj operator only knows that a string sits at one point on the page. It has no idea whether that string is a heading, a table cell, or a stray caption, which is exactly the distinction a DOCX file needs. PDF to DOCX is a real, working route on FileFlip, and it rebuilds an outline from where the ink landed rather than reading one that already existed. Simple, single-column pages come back clean; multi-column layouts and tables come apart more often, because a PDF page never carried the structure DOCX needs in the first place.

What you lose converting a PDF or a DOCX

FileFlip's PDF-to-PNG route renders at a fixed 2x scale with no control to raise or lower it, so a small page stays a small image. DOCX to PDF always lands on A4, so a document set up for Letter or Legal paper gets reflowed onto a different page shape rather than kept as drawn, and neither of these is adjustable from Advanced options today. No conversion, ours or anyone else's, turns a scanned picture of a page into real text without a separate OCR step.

Common questions

Does a bigger PDF mean it has more real text in it?

No. Our JPEG-compressed picture of a page came out smaller than the real, text-bearing version of the same page, 61 KB against 121 KB, while carrying zero extractable words to the real version's 68.

Does converting a PDF to PNG change its page size?

Not for a real PDF. The output always renders at 2x whatever the page's own /MediaBox says, confirmed above with a custom 300 by 150 point page.

Why doesn't my Word document's font show up in the PDF I convert?

Because DOCX to PDF goes through an HTML step that drops font styling, so the result uses mupdf's own built-in font instead of whatever you had set in Word. The text and structure make the trip; the exact typeface doesn't.

Can FileFlip read the words out of a scanned PDF?

No. A scan has no text operators in it at all, only an image, and reading letters out of a picture is a job for OCR, a separate technology covered in OCR, and why FileFlip does not do it.

Convert a PDF or a DOCX

FileFlip converts PDF to PNG and DOCX to PDF entirely in your browser, on the same mupdf and pandoc libraries this post measured. Nothing uploads, there's no account, and the file never leaves your machine. For what else a conversion can quietly drop along the way, see what a conversion actually costs you.

How we measured this

• Tools: pandoc 3.10.2 and mutool (mupdf) 1.28.2 on macOS, matching the major and minor versions FileFlip's worker runs (pandoc-wasm bundles pandoc 3.10, mupdf pins 1.28.0). ImageMagick 7.1.2-28 for the JPEG re-compression step.
• The 602-byte file: a hand-written PDF with /MediaBox [0 0 300 150] and one text run set in the standard Type 1 font Helvetica, cleaned with mutool clean.
• DOCX to PDF pipeline: the real route is pandoc docx-to-html, then mupdf writing the PDF after document.layout(595, 842, 11), straight from apps/nextjs/src/workers/document.worker.ts. Reproduced as pandoc in.docx -t html -o in.html then mutool convert -o out.pdf -F pdf -W 595 -H 842 -S 11 in.html.
• PDF to PNG pipeline: matches the worker's toPixmap(Matrix.scale(2, 2), DeviceRGB, false, true) call, reproduced as mutool convert -o out.png -F png -O resolution=144, since 2x of a 72-point base is 144 pixels per inch.
• The "picture" versions: the same rendered PNG wrapped into a PDF with mutool convert -o out.pdf -F pdf page.png, once as-is and once after magick page.png -quality 85 page.jpg.
• Text extraction: pdftotext against each PDF, counted with wc -w.
• Letter-size test: a <w:pgSz w:w="12240" w:h="15840"/> node inserted directly into a DOCX's word/document.xml before running the same pipeline.
• Caveat: the same libraries at the same versions FileFlip runs, invoked on the command line rather than through the browser's WebAssembly build. The uncompressed "picture" number is a worst case built to make a point, not what a real scanner typically produces.