Organize PDF pages
Drag page thumbnails into order, drop the ones you do not want, and rebuild the PDF.
How it works
Deleting a page and moving a page are the same gesture performed on the same thing, so this is one tool rather than two. You get a grid of every page in the document: drag a thumbnail to move it, click the × on a thumbnail to drop it, and use Reverse when a stack fed through the scanner back to front.
The jobs it actually covers are mundane and constant: pulling the fax cover sheet off a returned contract, deleting the blank versos a duplex scanner inserted after every odd page, putting an appendix back behind the section it belongs to, cutting the internal-only pages out of a report before you pass it on.
Typing an order like 3,1,2
There is also a plain text field holding the same arrangement as a list like 3,1,2. That field is not a fallback. For a 400-page deposition, typing the order you want is faster than dragging, it is the path that works from a keyboard or a screen reader, and it is the only way to ask for a page twice.
Write a number twice and that page is copied twice, which is how you repeat a separator or a terms sheet. Whichever one you touch, the other follows it.
What the rebuild preserves
The rebuild copies page objects. An empty document is created, the pages you kept are copied into it in the order you asked for, and the result is serialised. Nothing is rasterised, re-encoded or re-laid-out on the way through.
That is the difference between this and any workflow routed through printing or screenshotting: text stays real text you can select and search, vector diagrams stay vector, embedded photographs come out as the same compressed bytes that went in, and the page boxes that control trim and bleed travel with the pages they belong to. Page size and rotation are per-page properties, so a document mixing A4 portrait with a landscape foldout keeps both exactly as they were. Document title, author and subject are carried across to the new file; the rest of the info dictionary is not.
Why deletion can add bytes
Removing pages can make the file bigger, and you should know that before you see it. Two effects fight each other. The first is reachability: a PDF holds fonts, images and colour profiles as shared objects, so a resource reachable only from a page you deleted goes with it, while one shared with even a single surviving page stays at full size no matter how many pages you cut. Delete half of a 40-page report whose weight is one 8 MB photograph on page 3 and you save almost nothing; delete page 3 alone and you save 8 MB.
The second is the rewrite. Some PDFs store their internal index as compressed object and cross-reference streams, and this rebuild writes that structure out plainly. Measured on a 127-page print-ready book that does: re-saving it unchanged took it from 441 KB to 922 KB, and keeping only half its pages still landed at 498 KB, larger than the original. Files built without those structures went the other way in the same test: a 4-page scan lost 48% and a 19-page guide 39% when half their pages were dropped. The direction depends on the file you started with, not on how many pages you removed.
Bookmarks and fillable forms
Three things do not survive the rebuild, and none of them fails loudly enough to leave unsaid. The bookmark outline lives in the document catalogue rather than on the pages, so a rebuilt document has no bookmark panel. If you are reorganising a manual whose sidebar navigation matters, that navigation is gone and has to be rebuilt in a full editor.
Interactive form fields are the least obvious loss: the field's box belongs to its page and is copied with it, so whatever was typed into it still shows, but the document-level registry that makes a box fillable is not rebuilt. A fillable form flattens to its current appearance and nobody can edit it afterwards.
Internal links behave better. A link annotation belongs to the page it sits on, so it is copied, and it still resolves when its target page survived the edit; a link pointing at a page you removed has nothing left to land on and dangles. Cross-references written into the visible text are untouched, so the sentence "see page 12" keeps saying page 12 whether or not that is where the content ended up. Read the numbering afterwards, and use add-page-numbers if the arrangement you settled on needs a fresh sequence stamped over it.
Questions
Is my file uploaded?
No. The PDF is read into memory by the browser, rebuilt by a WebAssembly PDF library running in a Web Worker, and handed back as a download. Open the Network tab in developer tools and reorganise a document: you will see the code and worker chunks load, and not one request carrying your file. There is no server side to this tool for it to be sent to.
Why did the file get bigger after I deleted pages?
Because two things happen at once and only one of them is deletion. Page count is not what a PDF weighs: shared fonts and images stay as long as any surviving page uses them. Separately, some PDFs hold their internal index as compressed object and cross-reference streams, which this rebuild writes out plainly, making the file grow. On one 127-page book, re-saving it without changing anything went from 441 KB to 922 KB. Nothing was lost: the growth is structural redundancy and it compresses away, which makes compress-pdf a measured next step rather than a guess. Other files in the same test came out smaller, so this is a property of your document rather than of the tool.
Do bookmarks, links and form fields survive?
Links mostly do. They are copied with their pages and still resolve when the target page is one you kept, while a link to a removed page dangles. Bookmarks do not: the outline tree is a document-level structure and is not carried into the rebuilt file. Neither is the registry that makes form fields fillable, so a fillable form flattens to its current appearance: the values already in it still show, and nobody can change them afterwards. Text that reads "see page 4" is content rather than a link, so it stays as written and may no longer be accurate.
How large a document can this handle on a phone?
Tens of megabytes comfortably; a very large file is where it gets tight. Neither half of the tool decodes pages into pixels: thumbnails render only as they scroll into view, so a 500-page scan does not rasterise 500 pages to answer which ones you want, and the rebuild copies compressed objects rather than re-encoding them. What it does cost is the parsed object graph, which tracks page and object count rather than file size: measured, a 60 MB image-heavy PDF peaks at about 2.3 times its own size, while a 441 KB 127-page book costs around 32 MB because the pages, not the bytes, are the work. So a 200 MB scan is genuinely demanding on a phone even though a 400-page text document is not, and files over 200 MB are refused at selection with the size and the limit rather than reloading the tab at 60%.