Reorder PDF Pages

Upload PDF

How It Works

1. Upload your PDF, drag and drop a PDF file into the upload area or click to browse your device.
2. Reorder, delete or duplicate pages: drag page thumbnails to rearrange them. Use the delete (X) or duplicate buttons on any page card to remove or copy it.
3. Download your reordered PDF: click "Download Reordered PDF" to save the modified file back to your device. The original PDF is never changed.

Why Reorder PDF Pages?

Sometimes a PDF arrives with pages in the wrong order, a scanned document fed upside-down, a merged report where the appendix ended up before the summary, or a slide deck exported with the title page at the end. Rather than re-exporting from the source application (which often isn't available), you can fix the page order directly. This tool also handles the common cases of needing to remove a blank page, duplicate a signature page, or move an executive summary to the front. Everything happens in your browser using PDF-lib and PDF.js, so the file never leaves your device, ideal for contracts, tax returns, medical records, and anything else you wouldn't upload to a random server.

Features

• Drag-and-drop reordering: grab any page thumbnail and drop it in a new position. Works with mouse or touch.
• Delete and duplicate pages: each page card has a one-click X to remove and a copy button to duplicate.
• Live page thumbnails: see a rendered preview of every page so you know exactly what you're moving.
• Reset order: one click restores the original page sequence if you change your mind.
• 100% client-side: your PDF is processed entirely in your browser. No upload, no account, no tracking of file contents.

Frequently Asked Questions

Is my PDF file secure?

Yes, all processing happens in your browser. Your PDF file is never uploaded to any server, it stays on your device at all times.

Can I delete or duplicate pages?

Yes, each page has a delete button (X) and duplicate button (copy icon) to remove or copy pages as needed.

Does this work on mobile?

Yes, this tool works on mobile devices with both touch and drag-and-drop support for reordering pages.

Does this tool work with scanned PDFs?

This tool works with all standard PDF files. For scanned documents (image-only PDFs), text extraction features may be limited since the content is stored as images rather than selectable text.

Is there a page limit?

There is no fixed page limit. Processing speed depends on your browser and device capabilities. Documents with hundreds of pages will work but may take longer to process.

What "reorder PDF pages" actually means

At the user level, reordering is the operation of taking a PDF whose pages are in one sequence and producing a PDF whose pages are in a different sequence. Drag-and-drop UI; thumbnails on screen; drop a thumb in a new slot; download the result. At the file-format level, the operation is a manipulation of the page tree. Every PDF has a root catalog object that points to a /Pages node of /Type /Pages. The /Pages node has a /Kids array of references to its children, either leaf page objects (/Type /Page) or further intermediate /Pages nodes forming a tree. The /Count entry on each node carries the total leaf count beneath it, so a reader can find page N in O(log N) time without walking every leaf.

Reordering, in this representation, is just rewriting the /Kids array of the root /Pages node (or restructuring intermediate nodes if the tree is deep). The page objects themselves do not move or change; only the references to them do. This sounds simple and mostly is. The wrinkles are when individual page objects share resources (fonts, embedded images, content streams) with other pages: rewriting the tree must not orphan those shared resources, and the file's cross-reference table needs to be regenerated so byte offsets to every object are correct. A naive reordering implementation that just swaps /Kids entries without rewriting the xref table produces a corrupted PDF. Reorder libraries handle this by writing a fresh file end-to-end with a new xref table, not by patching the original.

How this tool works

This tool uses two PDF libraries in tandem: pdf-lib for output construction and PDF.js for thumbnail rendering. They handle complementary parts of the workflow. When you select a PDF, the browser File API hands the raw bytes to both libraries. PDF.js parses the file's display layer, calls getPage(n) for each page, and renders each page to a small canvas to produce the thumbnail grid you see. The thumbnails are client-side bitmap renderings; nothing about them is transmitted anywhere.

When you drag a thumbnail to a new position, only an in-memory JavaScript array of page indices changes. No PDF manipulation happens during dragging. The original PDF bytes sit untouched. When you click "Download Reordered PDF", pdf-lib takes the index array (e.g. [3, 0, 1, 2, 4] for a 5-page document where page 4 moved to the front) and constructs a new PDF: it loads the source into a PDFDocument, creates a fresh empty PDFDocument, calls copyPages(source, indices) to clone the requested pages, then addPage() for each cloned page in order. The result is serialised to a Blob, wrapped in a download URL, and offered to you.

copyPages does the heavy lifting: it traces every object the target pages depend on (fonts, embedded images, content streams, annotations, action dictionaries) and copies them into the new document, then rewrites the cross-reference table so every byte offset is consistent. The resulting PDF is structurally clean, identical in rendered output to the original on a page-by-page basis, just with the pages in the new order. No network request fires during any of this. You can verify it: open the browser developer tools to the Network tab, do an upload + reorder + download, and watch for any request with the file content. There will be none beyond the one-time CDN loads of pdf-lib (~1.1 MB) and PDF.js (~440 KB) which the browser caches.

Why two libraries instead of one

pdf-lib is an output-focused library: it can read PDFs at the structural level, modify the page tree, copy pages between documents, embed new content, and write a clean PDF. What it does not do is render pages to pixels. That is the domain of PDF.js, which implements the full PDF rendering specification, text layout, font rasterisation, vector graphics, transparency, blending modes, all the way to a canvas. For a reorder tool we need both. Reorder is a structural operation (pdf-lib's territory), but the UX requires showing the user a visual preview so they know which page is which (PDF.js's territory). A single library that did both would be larger; the two-library split is the pragmatic web-developer choice.

The cost is two CDN downloads on first visit (about 1.5 MB total compressed). The cost is paid once per browser per cache lifetime; subsequent visits load both libraries from cache instantly. There is no server component, and no part of the file leaves the browser.

Real-world workflows that drive page reordering

• Scanned documents in the wrong order. The scanner fed pages upside-down, or the user double-fed two pages and a third later got tagged onto the end, or the sheet feeder grabbed in reverse. Re-scanning is often impractical (the originals are gone, the scanner is at another office, the document is hundreds of pages). Reorder fixes it in seconds.
• Merged reports with appendices in the wrong place. Several source documents were combined into one PDF, and the order is not the editorial order: the appendix landed before the conclusion, the cover letter ended up at the back, the table of contents is in the middle. Common after using a merge tool that concatenates without prompting for order.
• Contract execution with separate signature pages. A signed signature page comes back as a separate PDF, and it needs to be the last page of the assembled contract (or the first, for some jurisdictions). Reorder inserts the signed page into its correct position in the master document, no need to print and re-scan.
• Legal discovery and litigation prep. Document productions arrive in Bates-stamp order, which is rarely the order useful for a brief. Re-ordering for hearing exhibits or trial binders is a routine task in litigation support, and doing it in a browser keeps privileged documents off third-party servers.
• Medical record sequencing. Clinical PDFs (intake forms, test results, treatment notes) arrive from multiple systems in arbitrary order. Care coordinators reorder them into a chronological or by-encounter sequence before sharing with specialists. HIPAA-sensitive content stays in the browser.
• Academic submissions and thesis assembly. A thesis with the abstract, chapters, references, and appendices in a specific committee-required order. Reorder lets the student fix the sequence without re-exporting from Word (which often resets formatting and breaks the table of contents).

Common pitfalls and what they mean

• Hyperlinks point to the wrong pages after reorder. The source PDF has hyperlinks or annotations that reference page indices directly (e.g. a Table of Contents link to "page 3" rather than to a named destination). After reorder, those references still point to the OLD page index. The fix is to flatten the source PDF with PDF Flatten before reordering, or accept that absolute page-number links will need manual repair afterwards. Named-destination links (the modern approach) survive correctly.
• The downloaded file is larger than the original. pdf-lib's copyPages does not deduplicate shared resources as aggressively as the source PDF may have. If pages 2 and 5 of the original shared a font subset and you reorder them apart, the new file may end up with two copies of the font. The difference is usually small (under 10 percent). Run the result through PDF Compress if size matters.
• Bookmarks or table-of-contents entries are now wrong. pdf-lib's page copy preserves explicit named destinations attached to copied pages, but the document outline (the bookmark tree) lives at the root catalog level and is not automatically rewritten when pages move. Reordered output keeps the bookmark text but bookmarks may point to wrong pages. Known limitation of the page-copy approach; the workaround is to re-add bookmarks after reordering with a dedicated outline editor (Adobe Acrobat Pro does this natively).
• Form fields stop working after reorder. If the source PDF has AcroForm fields, the field objects live at the document level (in /AcroForm /Fields) but their widget annotations live on pages. After reorder, the widgets move with the pages, but field-to-widget associations may not be perfectly preserved. The fix for "final, non-editable" workflows is to flatten the form before reorder; for "still fillable after reorder" use Adobe Acrobat Pro.
• Drag and drop doesn't work on my touchscreen. Some mobile browsers handle drag events inconsistently. This tool registers both HTML5 drag events (desktop) and touch events (mobile), but specific Android browser versions have known bugs with touch-and-hold drag. If drag fails on touch, try a desktop browser; the reorder result is identical regardless of where you do the dragging.
• The PDF has password protection. This tool cannot read the page tree of an encrypted PDF: pdf-lib needs to parse the structure, and parsing is gated by decryption. Unlock first with PDF Unlock, then reorder, then re-protect with PDF Protect if needed. The three-step pipeline is the standard workflow for editing secured documents.

Browser-only versus cloud reorder

Every cloud PDF-reorder service (Smallpdf, ILovePDF, PDF24, Adobe Acrobat Online, Sejda, Lumin, Soda) uploads your PDF to the operator's servers, renders thumbnails server-side, lets you drag in the browser against those server-rendered images, then sends your final order back to the server which produces the reordered PDF and serves it as a download. The privacy implications differ from a normal file upload in one small but interesting way: the operator necessarily reads the content of every page (to render thumbnails) before you have made any reorder decision. Even if you change your mind and never download the result, the operator has already processed the content.

This tool does not upload the PDF. pdf-lib and PDF.js both run in the browser tab. The file bytes are read once by the File API, fed into both libraries' parsers, and never serialised back to the network. The only network traffic is the one-time CDN fetch of the two libraries on first visit; subsequent visits are entirely offline-capable from cache. The trade-off is feature scope. Cloud services often bundle secondary operations: OCR scanned pages before reorder, convert attachments to PDF on the fly, sign-and-send after reorder. The browser-side tool here does just the reorder. For the focused «I need to fix the order and download» workflow, the browser is strictly faster (no upload wait, no upload size limits) and more private.

When another tool is the right choice

• PDFs over 200 MB on a memory-constrained device. The two libraries load the entire file into memory; very large files can cause the tab to crash. Use a desktop tool (Adobe Acrobat, qpdf CLI, PDFsam) for huge files.
• XFA forms or certificate-based encryption. pdf-lib does not handle Adobe-proprietary structures reliably. Adobe Acrobat is the canonical tool for those.
• Reorder that needs to preserve bookmark/outline structure. If the document has a complex outline and you need bookmarks to follow pages to their new positions, Adobe Acrobat Pro's Organize Pages feature handles this natively; pdf-lib does not.
• Automated batch reordering as part of a pipeline. For server-side or scripted reordering, use pdf-lib directly from Node.js (same library, no browser tab required), Python's pikepdf, or qpdf's CLI with explicit page-range syntax.

More frequently asked questions

Why are the page thumbnails small?

PDF.js renders thumbnails at a fixed size (~150 px wide) to keep memory usage manageable for documents with hundreds of pages. The exported PDF uses the FULL resolution source pages: the thumbnail rendering quality has zero impact on output quality. If the thumbnails are too small to see what is on each page, zoom your browser; the thumbnails scale up proportionally.

Does this work offline?

After the first visit, yes. pdf-lib and PDF.js are cached by the browser on first load (about 1.5 MB total compressed). Subsequent visits work without a network connection, as long as the browser cache has not been cleared. The PDF reorder itself never needed the network in the first place, only the library load does.

Can I reorder pages from multiple PDFs into one?

Not directly in this tool: the reorder UI assumes a single source document. The two-step workflow is: use PDF Merge to combine your sources into one PDF, then bring that combined PDF here to drag pages into the right final order. For more complex cross-document workflows (drag page 3 of file A between pages 5 and 6 of file B), Adobe Acrobat Pro's Organize Pages handles cross-document drag natively.

Should I reorder before or after signing, flattening, compressing?

The safe order is: reorder, flatten, sign, compress. Reorder first because subsequent operations may depend on the final page sequence. Flatten next because it bakes form fields into static content so downstream tools handle them uniformly. Sign after flatten because the cryptographic signature commits to the document's final byte sequence and any further change invalidates it. Compress last (optional) to reduce size for transmission. Skip any step you don't need.

Will OCR text layer be preserved?

Yes. OCR text is stored as invisible text on each page (a content stream marked as invisible), and that content stream is part of the page object. When pdf-lib copies a page, it copies the entire page object including its content streams, fonts, and any invisible OCR layer. Search-and-select still works on the reordered output exactly as it did on the original.

Is there a desktop or command-line equivalent?

pdf-lib runs in Node.js (npm install pdf-lib) and the reorder code is the same: copyPages(source, indices) then addPage() for each. For the command line, qpdf has a per-page selection syntax: qpdf --pages input.pdf 3,1,2,4 -- input.pdf output.pdf reorders pages directly. Python's pikepdf library mirrors the same operations with cleaner Pythonic syntax. Adobe Acrobat Pro's Organize Pages does it with a GUI and additionally preserves bookmarks/outlines correctly.

Related Tools