PDF Page Organizer

Reorganizing PDFs: What Actually Changes

A PDF is structured as a tree of pages indexed in the document catalog. The "first page" of a PDF is just whichever page reference appears first in the catalog's /Kids array. Reordering pages doesn't move bytes around in the file, it changes the order of those references. Rotating a page sets a single integer. Deleting a page removes one entry from the array.

This makes structural page operations lossless and fast. The page content (text, fonts, images, vectors) is never touched. The Organizer just rewrites the table of contents.

What the Organizer Does

Reorder. Drag a thumbnail to a new position. The Organizer rewrites the page tree so the dragged page sits at the target index. All other pages renumber accordingly. The underlying objects don't move; only the references do.

Rotate. Click rotate on a thumbnail to add 90 degrees. The page's /Rotate value updates (0 → 90 → 180 → 270 → 0). Viewers honor this when rendering; the content stream is unchanged. Means: copy-paste, text search, and accessibility readers see the original text orientation, regardless of how the page is visually rotated.

Delete. Remove a page from the tree. The page object remains in the file initially but is unreachable from the catalog; a clean re-save (or running through the PDF Compressor) garbage-collects it.

Duplicate. Add another reference to the same page object. Both copies share the same underlying content, fast and disk-efficient. Edits to one don't affect the other only if the content gets copied on write (pdf-lib copies on duplicate; some tools share until edited).

Undo / redo. Every operation pushes to a history stack. Stack persists across operations within a session; reloading the page resets.

What's Not Modified

The Organizer changes structure, not content. It does NOT:

• Re-encode or recompress images.
• Change fonts or text content.
• Strip metadata (use the PDF Metadata Editor for that).
• Compress streams (use the PDF Compressor for that).
• Re-flow text or change layout.

If your goal is "make this PDF smaller" or "anonymize this PDF" or "extract text from this PDF," the Organizer is the wrong tool. It's specifically for page-level reorganization.

Common Workflows

Workflow 1: Splitting a scan into chapters. You scanned a 200-page book as one PDF. You want chapter PDFs. Use the Organizer to delete pages outside chapter 1, save as chapter1.pdf. Reload the original, delete pages outside chapter 2, save as chapter2.pdf. Repeat. (Or use the PDF Splitter, which is faster for clean ranges.)

Workflow 2: Fixing scan orientation. A scanner that flips alternate pages produces a PDF with half the pages upside-down. The Organizer's per-page rotate fixes this in a few clicks.

Workflow 3: Removing a page mid-document. A signed contract has a page you need to redact entirely. Delete the page, save. Better for "remove" than redaction tools, which leave a placeholder. (Note: this changes page numbers, which may matter for legal documents, confirm with counsel.)

Workflow 4: Combining selected pages from multiple PDFs. Open PDF A, delete unwanted pages, save. Use the PDF Merger to combine that with selected pages from PDF B. (The Organizer doesn't merge across files; that's the Merger's job.)

What Survives Reorganization

The pdf-lib library handles cross-references with care:

• Internal page links (table of contents, "see page X" links) get updated to point to the moved pages. Tested.
• Bookmarks (outline tree) pointing to surviving pages: updated. Pointing to deleted pages: orphaned/broken.
• Form fields stay attached to their original page. Their tab order may shift if pages were reordered.
• Annotations (highlights, comments, stamps) move with their page.
• Embedded files (attachments) are not page-scoped; they survive unchanged.

What Doesn't Survive

• Page-specific JavaScript that references absolute page numbers ("on page 5, do X").
• Page-specific layer (OCG) visibility settings.
• Tagged PDF structure tree if pages are deleted, the tree may have dangling references to non-existent pages. Acrobat re-tags on save; this tool doesn't auto-repair the structure tree.
• Linearization, the "fast web view" optimization is broken by any structural change and must be regenerated.

For documents where the structure tree matters (PDF/UA accessibility, regulatory submissions), validate after reorganizing.

Thumbnail Rendering: Why It's the Bottleneck

To show you what's on each page, the Organizer renders a small bitmap thumbnail using PDF.js. Rendering is the expensive part: each thumbnail requires parsing the page's content stream, resolving fonts, and painting to a canvas. Memory usage scales with page count and complexity.

Strategies the tool uses to stay performant:

• Lazy rendering. Only visible thumbnails render initially; off-screen pages render as you scroll.
• Low DPI. Thumbnails are ~100×140px, not full-resolution. Massive memory savings.
• Cancellation. Scrolling fast cancels in-progress renders so the visible viewport rendering takes priority.

Even with these, a 500-page PDF strains browser memory. If you see slowdowns or crashes, split the document into chunks first with a server-side tool (qpdf, pdfcpu) and process each chunk.

Comparing to Server Tools

For batch operations on many PDFs or PDFs over 200 pages, server-side tools are more efficient:

• qpdf, qpdf --pages input.pdf 1,5,3 -- output.pdf reorders pages by position. Lossless, fast, no thumbnail rendering needed. Scriptable.
• pdftk (legacy but reliable), same operations, slightly different CLI syntax.
• pdfcpu, modern Go tool with similar capabilities and better Unicode support.
• Adobe Acrobat Pro, GUI thumbnail organizer, very polished.

The client-side Organizer wins on privacy (no upload), latency (no roundtrip), and convenience (no install). For 1-50 page documents, it's the right answer; for archival batch jobs, scripts are better.

Privacy

PDF.js renders thumbnails, pdf-lib rewrites the page tree, all in JavaScript memory in your browser. The file is read via FileReader, manipulated locally, and downloaded as a Blob, never uploaded. Open DevTools Network during a session: zero outbound requests. Sensitive documents, signed contracts, medical records, legal exhibits, stay on your machine.