Page reordering in PDF reveals a fundamental aspect of the format that many users find surprising: the physical order of data within a PDF file has no relationship to the logical order of pages as presented to the reader. A PDF stores its pages as individual objects scattered throughout the file, and the page tree structure — a hierarchical index rooted in the document catalog — determines the sequence in which pages are displayed. Reordering pages is therefore a matter of restructuring this tree, not moving data blocks around in the file.

The page tree in a PDF is defined by the ISO 32000 specification as a balanced tree of Page Tree Nodes (type Pages) and Page Objects (type Page). The root node contains a Kids array listing its children, which can be either page objects or intermediate tree nodes. Each intermediate node similarly contains a Kids array. The order of entries in these Kids arrays, read left to right and depth-first through the tree, defines the page sequence. To reorder pages, the tool rearranges entries in these Kids arrays so that the desired page sequence is produced when the tree is traversed.

A complication arises from attribute inheritance in the page tree. Parent nodes can define properties like MediaBox (page dimensions), Resources (fonts and images), and Rotate (page rotation) that are inherited by all descendant pages unless explicitly overridden. When pages are moved between different subtrees during reordering, they may lose inherited attributes from their original parent or inadvertently inherit attributes from their new parent. A robust reordering implementation resolves this by flattening inherited attributes onto individual page objects before restructuring the tree, ensuring that every page carries its own complete set of properties regardless of its position in the tree.

The cross-reference table does not need to change during reordering because object positions within the file remain the same — only the logical linkage between them changes. However, several document features depend on page order and must be updated. Page labels, which define the displayed page numbers (like "i, ii, iii" for front matter and "1, 2, 3" for body content), are stored as a number tree keyed by page index. When pages are reordered, this number tree must be rebuilt to reflect the new indices. Similarly, bookmarks (outlines) reference pages by object reference rather than page number, so they continue to point to the correct pages after reordering — but their visual order in the bookmark panel may no longer match the document flow.

Named destinations and hyperlinks use either page object references or page index numbers. Those using object references remain valid after reordering, while index-based references must be updated. Article threads, which define reading order through multi-column layouts, and logical structure trees used for accessibility tagging, also reference pages and may need adjustment. A thorough reordering tool addresses all of these dependencies to ensure the restructured document remains fully functional and navigable.