Reorder PDF Pages — Visual Drag-and-Drop Online

The scans came out in the wrong order, the contract appendices got mixed up, the title page ended up in the middle. Reordering pages blindly by numbers in a PDF editor is a chore. The "Reorder" tool in pdfredX shows all pages as thumbnails and lets you move them with a mouse or a finger: drag a card — the order changes. All in the browser, nothing uploaded to a server.

Step 01. Load the PDF

Open pdfredx.com and drag a PDF into the drop area — or pick it through your file browser. PDF.js renders each page into a thumbnail, and the document lays out as a gallery of cards. Not a single byte goes to a remote machine.

Step 02. Drag the pages

Grab a card and pull — a semi-transparent copy (ghost) appears under the cursor, and a faded trace stays in place. Hover over the page you want to place the dragged one before, and release: the order rebuilds instantly, the neighboring cards shift over.

• Move with a mouse or a finger — it works the same on a computer and on a phone.
• A short activation threshold (~9 px) — tells a drag from an accidental touch, so the gallery doesn't "jump" while you scroll on a touch screen.
• Remove an unneeded sheet — the 🗑 button on a card deletes the page; the rest keep their order.

You don't need to type any numbers — you see the pages themselves and lay them out like physical sheets on a desk.

Step 03. Save the result

When the order suits you, press "Create PDF". The app walks the gallery in the current order of cards and assembles a single file through jsPDF — the new page order goes straight into the exported document. The finished PDF downloads directly from the browser. Free, no registration, no server queue.

How it works under the hood

Reordering runs over the items[] array of pages that the app built at load time. The order of cards in the gallery is exactly the order of the array elements. Dragging is implemented on Pointer Events (one code path for mouse and touch): on release the app finds the card under the cursor and moves the element within the array:

const [item] = items.splice(fromIdx, 1);  // pulled the page from its original position
items.splice(toIdx, 0, item);             // inserted it before the target
render();                                  // redrew the gallery

The thumbnails themselves are not re-rendered — only the element's position changes. The order is applied to the final document only at the "Create PDF" step, so you can move cards as much as you like without reassembling the file.

Known limitations

Order is set by page boundaries. The tool rearranges whole sheets. Moving a fragment within a page or cutting it is a different task (there is a separate tool for spreads).

The export result is raster. During assembly pages are inserted as images, so the text in the final file cannot be selected, and hyperlinks and bookmarks of the source are not carried over. The reordering itself does not affect this — it is a property of the export.

Memory on large documents. All pages live in the gallery as thumbnails; on hundreds of pages scrolling can stutter on weak devices.

Need to combine several files into one before sorting? That is the Merge PDF tool. And to cut a document into parts — Split PDF.

Try it right now — pdfredx.com, no registration, your files stay with you.

A signed contract needs to be forwarded with its appendices in the right order. A couple of extra sheets have to come out of an HR package before sending. A bundle of scans has to be arranged in sequence for a submission. For all of these operations on closed, often already signed documents, an ordinary online service offers the same thing: upload the whole file to its server. That is, a contract with details, signatures and stamps travels to someone else's machine — for a simple rearrangement of sheets. Let's look at the risk and at the local alternative.

Where the document goes on server-side sorting services

When you upload a PDF to a typical online page organizer, the file travels in full to a remote machine. From there it follows the service's policy, which few people ever read:

• the document is stored in a contractor's temporary storage (AWS, GCP, Azure);
• it is processed on someone else's server;
• it is kept from a few hours to several days "for reliability";
• it is logged together with metadata — IP, time, file name and size.

For rearranging sheets this is an especially galling trade: the operation is purely visual, it needs no server-side computation at all — yet the price for it is full access to the contract's contents by an outside service. If the document holds personal data, commercial terms or signatures, the whole lot ends up on someone else's machine at once.

Local reordering: the document never leaves the tab

pdfredX rearranges pages without uploading the file anywhere. That is a consequence of the architecture, and you can verify it.

The file is read locally. PDF.js opens the document in the tab and draws the pages as thumbnails. There is no network request carrying your file.

Reordering happens in the tab's memory. Dragging cards, deleting extra sheets, the final assembly — all of these are operations on data that is already loaded. Nothing is sent anywhere.

The finished file is built on the client. jsPDF writes the new order into a PDF right in the tab and hands it to the browser for download — into your "Downloads" folder, not to a server and back.

It works offline. Load the contract, turn off the internet and rearrange the sheets — everything keeps working. The network is only needed to load the app once.

In practice: drag the thumbnails into the order you need, delete the extra pages with the 🗑 button and save the result. The document stays with you the whole time.

What we cannot guarantee — an honest disclaimer

Client-side processing protects a document from being sent to external servers, but it is not a shield against every threat, and promising otherwise would be dishonest.

Malware or a keylogger on the device. If the machine is compromised, a program can read files off the disk bypassing the browser entirely.

Browser extensions with broad permissions. An extension with "read data on all sites" access can, in theory, see the tab's contents. For sensitive documents, work in a profile without third-party extensions or in a private window.

The saved file stays on your disk. If the device is not protected by encryption, confidential files can be read by third parties with physical access.

We provide isolation at the level of the browser tab. The rest is on the user's side.

Rearrange and clean up pages without uploading the document to a server — pdfredx.com, free, no registration.

Dragging thumbnails is a familiar gesture, but several non-obvious decisions sit behind it. Native HTML5 Drag and Drop works poorly on touch screens and gives little control over the look of the dragged element. Mouse and touch events can be handled separately, but that is two parallel paths with duplicated logic. Let's break down how page reordering in pdfredX is built: why Pointer Events instead of native DnD, how the ghost clone is separated from the data, and why the whole order rests on a single splice.

The architectural choice: Pointer Events over DOM cards

Why not native Drag and Drop. Standard HTML5 DnD is designed to transfer data between elements and applications, but it is finicky on mobile and barely lets you style the "flying" element. For a gallery that has to work the same on desktop and phone, that is inconvenient.

Why Pointer Events. Pointer Events unify mouse, touch and stylus into a single stream of events (pointerdown / pointermove / pointerup). One branch of code — and the gesture works the same everywhere. What's dragged is ordinary DOM gallery cards (elements with data-id), not pixels on a Canvas: the thumbnails were already drawn by PDF.js at load time, and what needs to move is their representation, not a redraw of the image.

The implementation, piece by piece

The start threshold: separating a drag from a tap

On pointerdown the card and starting coordinates are remembered, but the drag does not begin yet. It starts only once the finger/cursor has moved past the threshold:

const THRESH = 9;
// ...in pointermove:
if (!moved && Math.hypot(dx, dy) < THRESH) return; // still jitter/a tap, not a drag

The 9 px threshold is critical on touch screens: without it, any tap on a card would start a drag, and the gallery would be impossible to scroll. Buttons and fields inside a card (🗑 delete, etc.) are excluded from capture by a separate check, so a click on them doesn't launch a drag.

The ghost clone: a visual copy detached from the data

Once the threshold is passed, a ghost is created — a clone of the card that flies after the cursor, while the original dims:

ghost = dragEl.cloneNode(true);        // a visual copy
ghost.style.cssText = 'position:fixed; pointer-events:none; z-index:9999; opacity:.82; ...';
document.body.appendChild(ghost);
dragEl.style.opacity = '0.3';          // a faded trace in the original spot
document.getElementById('SA').style.overflow = 'hidden'; // lock the gallery's scroll

The ghost is purely visual: pointer-events:none, so it doesn't intercept events and doesn't interfere with detecting which card we're over. It doesn't touch the data — it's a DOM copy, not an items[] element.

Detecting the target and reordering with a single splice

On release the app hides the ghost, asks the browser which card is under the drop point (elementFromPoint), and moves the element within the array:

ghost.style.display = 'none';
const target = getCard(document.elementFromPoint(x, y)); // the card under the cursor
// ...
const fromIdx = items.findIndex(x => x.id === dragId);
const toIdx   = items.findIndex(x => x.id === target.dataset.id);
const [item] = items.splice(fromIdx, 1);  // pulled out
items.splice(toIdx, 0, item);             // inserted before the target
render();

The entire reordering model is two splice calls over items[]. The array remains the single source of truth about order; the gallery and the future PDF simply read it. The ghost is hidden for the measurement, because otherwise elementFromPoint would return the ghost itself (it's under the cursor) rather than the card beneath it.

State cleanup

pointerup and pointercancel both lead to a shared cleanup(): remove the ghost, restore the original's opacity, unlock the #SA scroll, reset the flags. One cleanup path for both normal completion and gesture interruption — the state doesn't get stuck if the drag was cancelled.

Trade-offs and the limits of the approach

Reordering is by page boundaries. Whole sheet-cards move; this mechanism can't move a fragment within a page.

The order is applied at export. Dragging changes only items[] and the gallery view; the new order goes into the file at the jsPDF assembly step. That is cheap (you can drag endlessly without reassembly), but until you carry it into the export, nothing changes on disk.

Measurement via elementFromPoint. Target detection relies on the visible element under the point; on very dense grids the hit depends on exactly where the card is released (before which thumbnail the cursor is).

What's next

Multi-selection and moving a group — drag several marked pages at once in a single gesture.

Auto-scroll at the edges — when the ghost approaches the top or bottom of the gallery, smoothly scroll the list, so a page can be carried across a long document without manual scrolling.

Want to test the gesture — load a multi-page PDF on pdfredx.com and rearrange the pages by dragging. No registration, no file upload to a server.