Upload a PDF or supported document, rearrange the page order, and download a newly ordered PDF in seconds.
A PDF's page order is baked into a /Pages object whose /Kids array literally lists the leaf page references in display order — there's no separate "show pages 5, 1, 3" view layer. To change the reading order you have to rewrite that array, which is exactly what a reorder tool does. The page content streams (text, images, fonts) stay byte-identical; only the tree-of-references changes. Typical reasons people reorder:
The three tools all rewrite the /Pages tree but produce different outputs. Pick by what you want to end up with.
| Tool | Input → Output | What it changes in the page tree | Use when |
|---|---|---|---|
| Reorder PDF | 1 PDF → 1 PDF with same pages in new order | Reorders entries in /Kids array |
All original pages stay; only sequence changes |
| Split PDF | 1 PDF → many PDFs (per page, range, or multi-range) | Extracts subsets of /Kids into separate documents |
You need separate files (e.g. one chapter per PDF, or "pages 1, 10-15, 30" as four files) |
| Merge PDF | Many PDFs → 1 PDF | Concatenates /Kids arrays from each input |
Combining a cover letter, resume, and references into a single packet |
| Compress PDF | 1 PDF → 1 smaller PDF | Re-encodes images and streams; doesn't change /Kids |
The reordered PDF is too large to email or upload |
Reorder + Split is the most common combo: reorder the master into the order you want, then split off the section you need to send. Merge + Reorder handles cover-letter-plus-resume packets where the merge inserts in the wrong direction.
Knowing what reorder does and doesn't touch helps explain why some interactive elements survive and others don't.
| PDF object | Survives reorder? | Why |
|---|---|---|
| Page content streams (text, images, fonts) | Yes | Each page is an independent object referenced by /Kids; only the array order changes. |
Form fields (/AcroForm) |
Yes | Fields live in the document /AcroForm dictionary; widgets reference pages via /P, which still points at the same page object after reorder. |
| Form field values you've typed | Yes | Values are stored in field objects, not page streams. |
| Internal links pointing to named destinations | Yes | Named destinations resolve through /Names → still hit the right page after reorder. |
| Internal links pointing to explicit page references | Yes | /Dest arrays reference the page object directly, not a page number. |
Internal links pointing to page numbers (/PageNumber in some viewers) |
Sometimes | Mostly historical; some viewers may show the wrong target if a tool wrote page-number references. |
Bookmarks / outlines (/Outlines) |
Usually | Outline entries point at page objects via /Dest; the destinations resolve correctly. Some lower-quality tools rebuild the outline and break it. |
Page labels (/PageLabels — "i, ii, iii, 1, 2, 3") |
Order-dependent | The label tree maps positions to labels; after reorder the labels stay tied to positions, not pages, so they may need to be re-assigned. |
Tagged-PDF structure tree (/StructTreeRoot) |
Mostly | Structure elements reference content via marked-content IDs on pages; reorder doesn't break the references but does affect reading order for screen readers, which is the whole point. |
| Digital signatures | Invalidated | Any byte-level change to the file invalidates a signature. Reorder before signing, never after. |
In most cases yes. PDF bookmarks (technically "outline items") store their target as a /Dest reference to a page object, not a page number — so the bookmark still points at the same page after reorder. Some tools regenerate the outline from scratch and lose the original entries; xconvert preserves the existing outline so your table of contents still works. If your bookmarks were authored against named destinations (Adobe Acrobat's default), they're especially robust.
Yes. PDF form fields are stored in a document-level /AcroForm dictionary and each widget annotation points at its page via the /P reference. Reorder rewrites the order of pages in /Kids but doesn't touch /P — the widget still binds to the same page object, just at a new position in the document. Values you've already entered are stored on the field object itself, so they survive too. The one caveat: if a form has JavaScript that hard-codes "go to page 3 of this PDF," that script may now jump to the wrong page.
Reorder keeps every page and just changes the sequence. To remove pages, use Split PDF with "Pages by multi-range" — enter the ranges you want to keep (e.g. 1-5, 10-20) and the result excludes anything outside those ranges. That's the cleanest way to drop pages without installing a desktop editor. Reorder won't shrink your document; split with selective ranges will.
Not in one click — page order and page rotation live in different parts of the PDF (/Kids array order vs each page's /Rotate entry). The standard workflow is to reorder first, then run a separate rotation step on the output. Both operations preserve page content byte-for-byte, so doing them serially produces the same result as a single combined edit, just in two downloads. If your only issue is sideways scans, a desktop viewer (Preview on macOS, Adobe Reader on Windows) can rotate-and-save without a second tool.
xconvert doesn't hard-cap reorder; the practical limit is browser memory for rendering thumbnails. For comparison, Adobe's online rearrange tool caps at 1,500 pages and 100 MB; iLovePDF and Smallpdf don't publish official caps on their organize tools. If your PDF is over a few hundred pages, expect thumbnail generation to take several seconds — the file itself processes quickly because the tool only rewrites the page tree, not the page content.
No — printed page numbers are part of the page content stream (text laid down at design time, usually in the footer). They don't know what position they're in. After reorder, page 5 might now sit at position 1 but still have "5" printed in the footer. If you need re-numbered pages, you'll need to regenerate the document from the original source (Word, InDesign, LaTeX) — no PDF tool can rewrite content-stream text reliably across arbitrary fonts and layouts.
Yes. Digital signatures sign a byte-range of the PDF; any change — including reordering pages — produces a different byte sequence and the signature no longer validates. Always reorder before signing, and re-sign if you reorder a signed document. Certified-signature PDFs may also have permission flags that explicitly forbid page-tree modification; if so, the tool can't modify the file at all.
Files process on our servers and are deleted after the session ends. No account is required, no email gating, no watermark, and there are no per-file or per-day limits.
Print-to-PDF re-rasterises every page through a virtual printer, which can downgrade text (becomes images), kill copy-paste, strip form fields, drop bookmarks, and inflate file size. Reorder rewrites only the /Pages tree — every page object is preserved byte-for-byte, so text stays selectable, forms stay fillable, links stay live, and file size barely changes.