What is actually inside a PDF file

Guides · Updated 12 August 2026 · 8 min read

Almost everything people find annoying about PDFs — text that cannot be edited, copy-paste that produces gibberish, files that balloon to 40 MB, "deleted" content that comes back — follows from a single design decision made in 1993. Understanding that decision explains the rest.

A PDF describes a page, not a document

A word processor file stores meaning: this is a heading, this is a paragraph, this paragraph contains a sentence. The layout is computed from that meaning when you open it, which is why changing the margin reflows the whole document.

A PDF stores the opposite. It is a page description language — a close relative of PostScript, the language printers speak. Its content is a list of instructions along the lines of "set the font to Helvetica at 11 points, move to coordinate x=72, y=698, draw the glyphs I, n, v, o, i, c, e". There is no object in the file that says "this is a paragraph". There is often nothing that says where one word ends and the next begins — word spacing can simply be a horizontal jump between two drawing commands.

That is the whole trade-off of the format, and it was a deliberate one. Because the file specifies exact positions rather than intent, it renders identically on every machine, forever — which is precisely what a contract, an invoice or a scientific paper needs. The cost is that the structure a human reads into the page is not actually stored anywhere.

The four parts of the file

Open a PDF in a text editor and you will see readable fragments among the binary noise. Every PDF has the same four-part skeleton:

• The header. A single line such as %PDF-1.7 giving the version. It is the first thing any reader checks.
• The body. A pile of numbered objects. An object is one of a handful of types: a number, a string, a name (/Type), an array, a dictionary (key–value pairs), or a stream — a dictionary followed by a blob of bytes, usually compressed. Everything in the document is built from these.
• The cross-reference table. An index mapping each object number to its byte offset in the file. This is what lets a reader jump straight to page 400 of a 1000-page document without parsing the 399 pages before it.
• The trailer. Points at the document catalogue (the root object) and at the cross-reference table, and it is written last. PDF readers therefore read the file backwards: end first, then jump to whatever the trailer points at.

The pages themselves live in a tree hanging off the catalogue. Each page is a dictionary holding its dimensions (/MediaBox), its rotation, its resources (fonts, images), and a reference to one or more content streams — the actual drawing instructions.

Why copied text sometimes comes out as nonsense

A content stream does not contain the characters you see. It contains glyph codes, plus a reference to a font object that knows how to draw each code. When a PDF producer embeds a font, it usually embeds a subset: only the glyphs the document actually uses, renumbered to save space. The letter "A" might be glyph 3 in one PDF and glyph 57 in the next.

Turning glyph codes back into text requires a mapping — a /ToUnicode CMap — that the producer is supposed to include. It is optional. When it is missing, incomplete, or wrong, the page still renders perfectly (the glyph shapes are right there) but copying gives you the raw codes reinterpreted as characters. That is the origin of the classic symptom: a document that looks flawless on screen and pastes as ​#$%&@.

The same mechanism explains why ligatures break searching. If the producer drew "fi" as a single ligature glyph without mapping it back to two characters, searching for "file" finds nothing — the text layer contains something that is not the letters f and i.

Images, and where the megabytes go

Images are stored as stream objects called XObjects, each carrying a filter that says how the bytes are encoded: /DCTDecode for JPEG data, /FlateDecode for zlib compression, /JBIG2Decode or /CCITTFaxDecode for black-and-white scans.

Crucially, the image is stored at its original resolution regardless of how large it appears on the page. Scaling a 4000-pixel-wide photo down to a 5 cm thumbnail in your layout tool changes one number in the content stream — the drawing matrix — and nothing about the stored data. The full-resolution photo is still in the file. This single behaviour accounts for the majority of unexpectedly enormous PDFs.

It has a security consequence too. Cropping an image in many tools only adjusts the visible region; the pixels outside the crop remain in the file and can be recovered by anyone who extracts the image stream.

Incremental updates: why deleted content can survive

PDF supports incremental updates. Instead of rewriting the file when you annotate or sign it, a writer can append the changed objects, a new cross-reference section and a new trailer to the end of the existing bytes. The old objects are still physically present; the new cross-reference table simply stops pointing at them.

This is what makes digital signatures possible — a signature covers a byte range, so the signed original must remain intact underneath any later additions. It is also why "redaction" done by drawing a black rectangle is not redaction at all. The rectangle is a new drawing instruction layered on top; the text underneath is untouched, still in the content stream, and still selectable. Real redaction means removing the underlying objects and rewriting the file.

The same applies to page deletion in some tools: if the tool only edits the page tree, the content of the removed page may still be sitting in the body of the file. A tool that rebuilds the document by copying the surviving pages into a fresh file leaves nothing behind — which is a meaningful difference when the pages you removed were the confidential ones.

What this means when you edit a PDF

Set against that structure, the everyday behaviour of PDF editors stops being mysterious:

• Editing a sentence is genuinely hard. There are no paragraphs to reflow. An editor has to guess where a text block begins and ends, re-measure the glyphs in the embedded font subset, and rewrite the drawing commands — and if the new text needs a character the subset does not contain, the font has to be re-embedded.
• Page-level operations are easy and lossless. Reordering, rotating, deleting, merging and splitting only touch the page tree and page dictionaries. The content streams are copied byte for byte, so nothing is re-encoded and no quality is lost, however many times you do it.
• Watermarks and page numbers are appended, not overlaid. They become extra drawing instructions in the page's content stream, which is why they survive printing and emailing — and why undo has to happen before saving.
• Every rebuild drops what it does not copy. Rebuilding a document from its pages carries the pages across but not necessarily the document-level metadata, which has to be written back explicitly.

The practical rule that falls out of all this: prefer page-level operations wherever you can, and treat text editing inside a PDF as a last resort. If you still have the source file, changing it there and re-exporting will always give a cleaner result.

Frequently asked questions

Is a PDF a compressed format?

Partly. Individual streams — content streams, images, embedded fonts — are usually compressed with Flate (zlib) or, for photographs, kept as JPEG data. The file structure around them is not. This is why zipping a PDF rarely saves much: the bulky parts are already compressed.

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

Because a scanned PDF contains no text objects at all — only a picture of a page. Selection works on text drawing instructions, and a scan has none until OCR adds an invisible text layer.

Does deleting a page make the file smaller?

Only if the tool rewrites the file rather than appending an incremental update. A tool that rebuilds the document from the surviving pages produces a genuinely smaller file; one that merely edits the page tree may leave the old content in place.

What is the difference between PDF and PDF/A?

PDF/A is a restricted profile of PDF intended for long-term archiving. It forbids anything whose rendering depends on the outside world — external font references, JavaScript, encryption, unembedded colour profiles — so the file is guaranteed to render the same way decades later.

Who controls the PDF format?

Adobe created it, but since 2008 PDF has been an open ISO standard (ISO 32000). Anyone can implement a reader or a writer without permission, which is why so many independent PDF libraries exist.

Further reading

• Why PDF files get so large — and what actually shrinks them
• What PDF metadata reveals about you
• Scanned PDF vs text PDF: what OCR does