How PDF Files Work: Objects, the Cross-Reference Table, and Why PDFs Are Hard to Edit

If you have ever opened a PDF in Notepad or TextEdit, you saw something like %PDF-1.7 on the first line and then a wall of unreadable characters. Underneath is a structure that is simpler than it looks, and once you know it, several everyday annoyances make sense: why merging two PDFs loses the bookmarks of the second, why splitting a file can make the pieces add up to more than the original, and why changing one word in a PDF is so much harder than in a word processor.

Where PDF came from

In 1991 Adobe co-founder John Warnock wrote an internal memo, later known as the Camelot paper, arguing that businesses needed a universal way to send documents between different machines, operating systems and networks and have them look the same everywhere. Adobe already had PostScript, the page description language inside laser printers. But PostScript is a full programming language: to draw page 10 you generally had to run the program through pages 1 to 9 first, and a file could loop, branch and compute.

PDF kept PostScript’s imaging model — lines, curves, text and images placed at coordinates — dropped the general-purpose programming, and wrapped the result in a file structure that lets a reader jump straight to any page. Adobe shipped it with Acrobat 1.0 in June 1993.

Adobe published each specification as it went, from PDF 1.0 through 1.7. In 2008 PDF 1.7 became the international standard ISO 32000-1. Its successor, PDF 2.0 (ISO 32000-2), appeared in 2017 as the first version developed entirely within an ISO committee rather than by Adobe alone, and a corrected “dated revision” followed in 2020. Since April 2023 the PDF Association, with sponsorship from Adobe, Apryse and Foxit, has made ISO 32000-2 available for download at no cost.

The four parts of a PDF file

Part	What it holds
Header	A first line such as %PDF-1.7 giving the version
Body	Numbered objects
Cross-reference table (xref)	The byte offset where each object starts
Trailer	Which object is the document catalog, and where the xref is

An object in the body looks like this:

4 0 obj
<< /Type /Page /Parent 2 0 R /MediaBox [0 0 595 842]
   /Contents 5 0 R /Resources << /Font << /F1 6 0 R >> >> >>
endobj

4 0 obj means “object number 4, generation 0”. The << >> brackets hold a dictionary of name–value pairs, and 5 0 R is a reference: “go and look at object 5”. This page is A4 (595×842 points, a point being 1/72 inch), its drawing instructions are in object 5 and its font is object 6.

The whole document is a graph of such references. The trailer points to the catalog; the catalog points to the page tree, the bookmarks (Outlines) and the form definition (AcroForm); the page tree points to each page; and each page points to its content, fonts and images.

A viewer does not read the file from the top. It jumps to the end, reads the number after startxref to find the cross-reference table, looks up the byte offset of the object it needs and seeks straight to it. The specification fixes every xref entry at exactly 20 bytes, so the position of object n’s entry can be computed rather than searched for. That is why a 500-page PDF can open on page 300 almost instantly.

PDF 1.5 added object streams, which pack many small objects into one compressed stream, and cross-reference streams, which compress the xref itself. That is why a modern PDF opened in a text editor shows so few readable objects: most of them are inside compressed streams. How much that saves is covered in Why PDF compression varies.

Incremental updates: edits appended to the end

A PDF can be saved without rewriting the whole file. In an incremental update, only the changed objects are appended to the end, followed by a new cross-reference section listing just those objects and a new trailer. The new trailer records where the previous xref was, so a viewer walks back from the newest section and always finds the latest version of each object.

Two consequences follow. The first is digital signatures. A signature covers the bytes up to the moment of signing, so later changes can be appended without breaking it — and a validator can tell exactly what was added after the signature. The second is privacy. In a file saved incrementally, text you deleted or a form value you overwrote may still sit, intact, earlier in the file. If you removed something sensitive, the file needs a full rewrite — “Save As” or an optimise step — before the old revision is really gone.

Text is stamped at coordinates, not written in sentences

Decompress a page’s content stream and you find instructions like these:

BT
/F1 12 Tf
72 770 Td
(Hello) Tj
ET

Begin text, select font F1 at 12 points, move to (72, 770), show “Hello”, end text. There are no paragraphs, no line breaks and nothing that says this line follows that one. A word processor has already broken the paragraph into lines and spaced the letters; the PDF records only the final result, as glyphs or runs of glyphs pinned to positions. In a justified paragraph the extra space between words is written out as numbers too.

So when you change a word, the rest of the line does not reflow. Replace “Main St” with “Main Street” and the new text overlaps whatever follows. For an editor to reflow the line properly it first has to guess where the original paragraph started and ended. Tables are worse: the grid is separate line segments, and the text simply happens to sit on top. When a PDF-to-Word conversion comes out with a hard break at the end of every line, or a page full of floating text boxes, that is the converter failing at exactly this guesswork.

Copying text that comes out as gibberish has the same root. The bytes inside (Hello) can be glyph numbers in the embedded font rather than character codes. A separate mapping called ToUnicode tells software which Unicode character each glyph represents; if it is missing or wrong, the page looks perfect on screen but pastes as nonsense.

Fonts contain only the letters you used

To look the same on a machine that does not have the font, a PDF carries the font inside it (embedding). A full font can be large — a CJK font with thousands of characters can run to several megabytes — so most PDFs embed a subset holding only the glyphs actually used. The specification marks a subset by prefixing the font name with six capital letters and a plus sign. If a PDF’s properties list a font like ABCDEF+Calibri, that is a subset.

Subsetting is another reason editing is hard. Try to type a character the original document never used and the embedded font simply does not contain its shape. The editor has to substitute another font or find the full font installed on your computer, and if neither is available the character cannot be added in that typeface.

Where the structure shows up in everyday tasks

Merging. A merge tool moves the second file’s page objects, and everything they reference, into the first file and renumbers them. Bookmarks and form definitions live in the catalog, not on pages, so moving pages does not bring them along. That is why Merge PDF keeps the bookmarks of the top file only.

Splitting. Fonts and logos are stored once and shared by object number. Split a document ten ways and every piece needs its own copy of the shared resources, so the pieces together weigh more than the original. That is what you are seeing when Split PDF produces files larger than you expected.

Compressing. Text and vector drawings are small to begin with. Most of a PDF’s weight is image streams and embedded fonts, so that is mostly where Compress PDF can make savings, by lowering image resolution and quality. A file saved incrementally many times, with old revisions piling up, can also shrink just by being rewritten.

Inspecting. Which version a file declares, which fonts are embedded as subsets, and what MediaBox and CropBox each page has can all be checked with PDF Info. It is the first place to look when a print shop tells you a font is not embedded.

Common misconceptions

• “PDFs can’t be edited.” They can: incremental updates, forms and annotations all exist to support changes. What PDF lacks is editing at the level of paragraphs; the unit of change is the object.
• “A PDF contains the original document.” Usually it contains only the printed result. Some applications tuck their own editable data inside as well, but the PDF format does not require it.
• “A higher version number is better.” The header version is only the ceiling of features the file may use. Many applications still write 1.x files, and saving as PDF 2.0 does not improve quality.
• “Cropping removes content.” Page cropping usually just shrinks the CropBox, the visible area. Everything outside it is still in the file.