Understand the hidden structure inside a PDF

A PDF feels like a document because it opens as pages. Underneath, it is closer to a small database of numbered objects with an index at the back. Some objects describe pages. Some describe fonts, images, colour spaces, annotations or metadata. Some are compressed streams of instructions that tell a viewer how to paint marks onto a rectangle.

That design is why PDFs are so dependable for display and so awkward for editing. The format was built to preserve a finished page, not to remember that a particular block used to be the second paragraph of a report or the third column of a table. Once you know that, familiar frustrations start to make sense: text copies in the wrong order, a damaged download will not open, and a black box drawn over a name may not remove the name from the file.

Match the symptom to the PDF layer

Use the visible symptom to choose the first inspection instead of treating every problem as generic corruption:

Symptom	Likely layer to inspect	Useful next check
Text copies in the wrong order	Drawing order, tags, or positioned text	Extract a page and compare columns and headings
Text looks right but copies as odd characters	Font encoding or missing character mapping	Compare native extraction with the visible glyphs
The file will not open after download	Cross-reference map, trailer, or missing bytes	Diagnose a copy with the repair workflow
Covered text remains searchable	Original page content beneath an overlay	Use destructive redaction and search the output
A deleted value remains in the bytes	Incremental save history or hidden structures	Inspect the release copy for retained content
File size is unexpectedly large	Images, embedded resources, or repeated revisions	Analyse contributors before compressing

One file can have more than one problem. The table narrows the starting point; the output still needs page, text, and structure checks.

A PDF is a container of numbered objects

Open the structure of a simple PDF and you will find objects with numbers such as 4 0 obj. Those objects refer to one another. The catalogue is the top-level object. It points to the page tree. The page tree points to page objects. Each page object points to its content stream and to the resources needed to draw that stream.

The page tree matters because a PDF may contain hundreds or thousands of pages without storing them as one long list. A reader can walk the tree, find page 237 and load only the objects needed for that page. That is one reason large PDFs can open quickly once their structure is intact.

A page object usually has a media box for the page size, a content stream for the marks on the page, and a resource dictionary. The resource dictionary gives short internal names to fonts, images and colour spaces. The content stream then uses those short names. It might say, in effect, use font F3, move to these coordinates and draw these glyphs.

This object model is useful when you use the text extraction tool. The tool is not reading a word-processing file. It is walking page objects, decoding streams and trying to rebuild useful text from drawing instructions.

The content stream is not a document model

The most important idea is that a PDF content stream is a list of operations. It says where to move, which font to use, what size to set, which path to stroke, which image to paint and where each glyph should appear. It does not have to say, "this is a heading", "this is paragraph two", or "these cells form a table".

That is why copy and paste can feel chaotic. If the file draws the left column, then the right column, then a header, extraction may follow that order. If each word was positioned separately, a reader has to infer spaces. If text was converted to outlines, there may be shapes on the page but no text to copy at all.

Tagged PDFs add a separate structure tree that can name headings, paragraphs, figures, tables and reading order. Without those tags, the page may look fine to you while assistive technology or extraction software sees only a pile of marks. The visual page is not the same as a logical document.

Tables show the limitation clearly. A table in a PDF can be nothing more than lines and positioned text. Unless the file contains tags or a converter rebuilds structure heuristically, there are no true rows, columns or header cells. That is why exported tables often need manual checking before anyone trusts the numbers.

Fonts, encodings and strange copied text

Fonts inside PDFs are more complicated than the font menu in a word processor. A PDF may embed a whole font, embed only the characters used, or rely on a font available on the reader's system. Embedding is what makes a page look the same on another computer. Subsetting keeps file size down by storing only the glyphs needed for that document.

A glyph is the shape drawn on the page. Text extraction also needs to know which character that shape represents. That mapping is not always simple. A file may use a custom encoding where the byte value for a visible letter does not match normal Unicode. Good PDFs include mapping data so extraction can translate the glyphs back into characters. Poorly made PDFs may not.

This is why copied text can contain odd symbols, missing spaces or broken ligatures. The page renderer only needs enough information to draw the shape. Copying requires a second layer of meaning. When that layer is absent or wrong, the visible text and the extracted text diverge.

The cross-reference table and trailer are the map

Near the end of many PDF files is a cross-reference table, often called the xref table. It records where each numbered object starts in the file. The trailer points to key objects such as the catalogue and gives the reader the final clues needed to open the document.

If a download is truncated, the visible page data may still be present in the bytes you received, but the map can be missing or incomplete. A reader may not know where the catalogue is, which page tree to follow, or where an object starts. That is why a partly downloaded PDF can fail so completely instead of opening the first few pages like a damaged video.

Some damaged files can be reconstructed by scanning for object markers and building a new index. Others cannot, especially if the missing part contained objects required by many pages. The repair PDF tool is for that salvage attempt: it tries to recover a usable structure, but it cannot invent bytes that were never downloaded.

Incremental updates leave history behind

PDFs can be updated incrementally. Instead of rewriting the whole file, an editor can append new objects, a new xref section and a new trailer. The latest trailer points to the newest version, while older objects remain earlier in the file.

This is efficient and useful for signatures, comments and small edits. It is also a privacy trap. If a name was visible in an earlier version and later covered or replaced, the old object may still exist in the bytes. A normal viewer shows the latest revision, so you may not notice the retained content.

That is why cosmetic redaction is unsafe. Drawing a black rectangle adds more page content; it does not necessarily remove the old text beneath it. Before sharing sensitive material, run a check with the privacy scanner and use a redaction workflow that deletes content rather than hiding it.

Compression makes the file smaller and harder to inspect

Many PDF streams are compressed. Page drawing instructions, images, font data and object streams may use filters such as Flate compression. Compression keeps file size reasonable, especially when a document contains repeated resources or large text streams.

The trade-off is that a PDF is not usually readable by opening it in a text editor. The object wrappers may be visible, but the important streams can be compressed binary data. Tools have to decode the filters before they can inspect content, extract text or rebuild damaged objects.

A practical mental model helps: a PDF is not a paper page trapped in a file, and it is not a word-processing document with fixed pages. It is a container of objects, streams, resources and indexes designed to paint a page reliably. When the right structure is present, it can also be searchable, accessible and safe to share. When that structure is missing or damaged, the visual page may be all that remains.

A short checklist

• If text copies badly, suspect missing tags, custom encodings or unusual draw order rather than user error.
• If a file will not open after a failed download, repair is about rebuilding the object map, not merely changing the filename.
• If you edited or covered sensitive text, scan for hidden content before sharing.
• If you need paragraphs, headings and table structure, keep the source document as well as the PDF.