Free PDF Page Editor Online

Delete unwanted pages and rearrange page order in your PDF. 100% client-side · your files stay private.

Your files never leave your device
Drop PDF here or click to browse

Supports PDF files · up to 50 MB

What This Editor Actually Does

A PDF page editor operates at the structural level of a PDF document, it manipulates the order, presence, and orientation of whole pages without touching the rendered content of any individual page. You drop a PDF into the editor, the tool parses its page tree and shows one card per page with the page number and dimensions, you tick checkboxes for pages to remove, drag or arrow-press to reorder, and download the modified PDF. The original file on your disk is never modified, the edited version is a new download. Every operation runs in your browser via JavaScript, powered by the pdf-lib library (a pure-JavaScript PDF reader and writer by Andrew Dillon, MIT licence, on GitHub at Hopding/pdf-lib) loaded from a CDN. No upload, no server processing, no telemetry, verify in DevTools' Network tab while you click Delete Selected and Download, or take the page offline (airplane mode) after pdf-lib has loaded and the editor still works. Files up to 50 MB process comfortably; larger files work but take longer depending on browser and device memory.

PDF as a Format, A Brief History

PDF (Portable Document Format) was created at Adobe by John Warnock (the company's co-founder) and grew out of his 1991 internal proposal nicknamed "Camelot." The first public release, PDF 1.0, shipped with Adobe Acrobat 1.0 in June 1993 at a launch event in New York. The original problem PDF solved was print-fidelity portability: take any document, package it with embedded fonts and exact layout, and any reader on any operating system reproduces it pixel-for-pixel. PDF stayed proprietary for fifteen years before Adobe released the spec to ISO. PDF 1.7 became ISO 32000-1:2008 in July 2008, the spec at the heart of essentially every PDF in active circulation today. PDF 2.0 followed as ISO 32000-2:2017, with a revised second edition published in December 2020 to clarify ambiguities. In April 2023, Adobe issued a patent waiver explicitly granting royalty-free implementation rights for PDF, removing the last legal friction for open-source readers and writers. The format's structural unit is the page tree (/Pages dictionary with a /Kids array). A page editor like this one walks the tree, removes or reorders entries in /Kids, and writes a new file with the surviving pages re-numbered. Page content streams themselves are untouched, which is why the operation is fast even on large documents and why the visual content of every page is preserved bit-exact.

The pdf-lib Library Doing the Work

pdf-lib is the pure-JavaScript PDF library that makes browser-side editing practical. Andrew Dillon released it under the MIT licence and the project ships as a single bundle that runs in any modern browser, no native dependencies, no WebAssembly required for the basic operations. It can parse, modify and serialise PDFs end-to-end: read existing documents, copy pages between documents, embed PNG and JPEG images, draw text with embedded fonts, modify form fields, and write the modified document back as a Uint8Array suitable for download. The alternative architecture (server-side PDF editing) is dominant in commercial PDF tools because PDF processing has historically been hard. Smallpdf, iLovePDF, Sejda, Soda PDF, ILovePDF, PDF24 and the dozens of competitor sites all upload your file to a server, run pdf-lib or similar (or Ghostscript, qpdf, or PDFtk on the backend), then send the modified file back. The trade-off: server-side handles arbitrary file sizes and complex operations more reliably, but every page of every document you edit lives in someone else's logs for some duration. Browser-side via pdf-lib trades a 50 MB practical ceiling and a slightly limited operation set for "the file never leaves your device." For sensitive documents (contracts, medical records, bank statements, internal docs) that trade is worth making.

How this tool works under the hood

A PDF's page collection is defined by the page tree described in ISO 32000-2 section 7.7.3. The document catalog dictionary has a /Pages entry that points to the root node of the tree. That root has /Type /Pages, a /Count entry giving the total number of leaf pages beneath it, and a /Kids array of references to its children. Children are either leaf page objects (/Type /Page) or further intermediate /Pages nodes. The tree is balanced so that a reader can find page N in O(log N) time without walking every leaf, which is what makes random page access fast in 500-page documents.

When you select a PDF, the browser File API hands the raw bytes to pdf-lib, which parses the document structure into an in-memory tree of objects. The tool calls pdfDoc.getPageCount() to count leaves and iterates pdfDoc.getPage(i).getWidth() and getHeight() for each page, producing the grid of cards you see (page number plus dimensions in PostScript points, where 1 point equals 1/72 of an inch). Ticking a checkbox or pressing an arrow only updates a JavaScript array that tracks which page references survive and in what order. The original PDF bytes sit untouched in browser memory until you click Download.

On Download, pdf-lib does the heavy lifting through copyPages. The tool calls PDFDocument.create() to build a fresh empty document, then newDoc.copyPages(sourceDoc, indices) where indices is the array of source-page positions in the order they should appear in the output. copyPages traces every object each requested page depends on (embedded fonts, image XObjects, content streams, annotations) and copies them into the new document, then regenerates the cross-reference table so every byte offset is consistent end-to-end. The output is a structurally clean PDF, identical in rendered output to the original on a page-by-page basis. No network request fires during any of this. Open the browser developer tools to the Network tab during the operation and you will see nothing beyond the one-time CDN load of pdf-lib itself (about 380 KB minified, cached by the browser after the first visit).

When You Actually Need a Page Editor

The Competitive Landscape, Browser vs Server vs Native

Three categories of PDF editor compete for the same user. Native desktop tools: Adobe Acrobat Pro (the canonical reference, US$19.99/month subscription), Foxit PDF Editor, Nitro PDF, PDF Studio, Apple Preview (built into macOS, surprisingly capable for page-level editing), install on your computer and work offline against your local files. They handle the largest files and the deepest editing operations, but they require a download and (for the commercial ones) often a paid licence. Server-side web tools: Smallpdf (Switzerland-based, founded 2013), iLovePDF (Spain, also 2013), Sejda (USA), PDF24 (Germany), Soda PDF (Canada), Adobe's own Acrobat Online, handle PDF operations through file upload, processing on the provider's infrastructure, and download back. They scale to large files and complex operations, but every file passes through someone else's servers. Browser-side tools like this one use pdf-lib, PDF.js (Mozilla's PDF renderer, written by Andreas Gal and others starting in 2011 and now bundled with Firefox) or pdf-lib-extra to do the work entirely on your device. They have file-size limits dictated by browser memory but never see your file content. For one-off page edits on documents that contain anything sensitive, the browser-side option is the right shape, the choice is essentially "is the convenience of upload-it-to-a-server worth the privacy cost on this particular file?" For routine work on internal documents, almost always yes. For contracts, finances, medical records, or any document you wouldn't post on the public web, almost always no.

What This Editor Does and Doesn't Do

Out of scope: editing the content of individual pages (text, images, form fields), splitting one PDF into multiple files (use the dedicated PDF Split tool), merging multiple PDFs into one (use PDF Merge), compressing pages to reduce file size (use PDF Compress), redacting sensitive content with permanent black bars, or signing PDFs digitally. For these operations, the dedicated tools or a desktop PDF editor are the right fit.

Common pitfalls and what they mean

Privacy: The File Stays on Your Device

Every cloud PDF page editor (Smallpdf, iLovePDF, PDF24, Adobe Acrobat Online, Sejda, Soda PDF) uploads your file to the operator's servers, parses it server-side, lets you click delete or drag thumbnails against server-rendered previews, then sends a modified copy back as a download. The privacy implications differ from a normal file upload in one important way: the operator necessarily reads the content of every page (to render previews and to count and identify pages) before you have made any deletion or reorder decision. Even if you change your mind and never download the result, the operator has already seen the content. Major providers publish privacy policies committing to deletion within hours and TLS encryption in transit, and they have strong commercial reasons to comply with those policies, but "deleted within an hour" is not "never seen." PDFs routinely contain medical records, bank statements, signed contracts, identity documents, internal company memos, and draft legal filings; for these documents, the policy distinction matters.

This editor does not upload anything. pdf-lib runs in your browser tab and receives the file bytes through the File API, returning the modified bytes back to the same tab as a Blob that becomes a download. You can prove it: open the browser developer tools to the Network tab before you click Download Modified PDF, run the operation, and observe that no requests are made with your file content. The only network traffic is the one-time CDN fetch of pdf-lib on first visit (about 380 KB minified), which happens once and then sits in the browser cache. Take the browser offline with airplane mode after the page has loaded and the editor still works on local files. The trade-off is feature scope: cloud services often bundle secondary operations like OCR before editing, automatic conversion of attachments, or sign-and-send-after-edit flows. This tool does just the page-level delete and reorder. For that focused workflow, the browser-side tool is strictly faster (no upload wait, no upload size limit) and meaningfully more private.

When another tool is the right choice

Frequently Asked Questions

Is my PDF uploaded to a server?

No. All processing happens in your browser via the pdf-lib JavaScript library, which runs in your tab. Your file is read into the browser's memory, manipulated in JavaScript, and the modified version is offered back to you as a download. The only network traffic is the one-time CDN load of pdf-lib itself when the page first opens. Verify in DevTools' Network tab while you delete pages or click Download, no requests fire that include your file content.

What is the file size limit?

PDFs up to 50 MB process comfortably on most modern browsers and devices. Files larger than 50 MB will work but may briefly freeze the tab while pdf-lib parses the page tree, especially on lower-memory devices. The fundamental limit is browser memory rather than a hard cap; very large PDFs (hundreds of megabytes) may be better suited to a desktop tool like Adobe Acrobat or Apple Preview.

Can I undo my changes?

You can keep changing the page selection and order before downloading, nothing is committed until you click Download Modified PDF. Refreshing the page or clicking Clear resets to the original document. Once downloaded, the modified file is a fresh PDF; the original on your disk is never overwritten, so you always have the unmodified version to start over from.

Does this work with scanned PDFs?

Yes. Page-level operations (delete, reorder) work identically whether each page contains selectable text or a scanned-image bitmap, the editor moves whole pages as opaque blocks of content. The page count, page numbers and dimensions display correctly for image-based pages too. What this editor doesn't do is OCR the scanned text or modify the image content of any page; for those operations a dedicated OCR tool or a desktop PDF editor with OCR features is required.

Does this work on mobile?

Yes for small files. Mobile browsers have less memory and slower JavaScript engines than desktop, so very large PDFs may freeze the tab or crash. The drag-and-drop affordance also works less well on touch devices, use the file picker (tap "click to browse") instead. For one-off page deletes on smaller PDFs, mobile works fine; for large files, switch to desktop.

What about password-protected PDFs?

pdf-lib's built-in support for encrypted PDFs is limited compared to Adobe Acrobat. If a PDF is password-protected with user-level encryption, the editor may fail to load it or may load it without the ability to write changes. The workaround: open the PDF in a desktop tool that knows the password, save it as an unencrypted copy, then edit the unencrypted version in this tool. Re-encrypt afterwards if you need password protection on the output.

More frequently asked questions

Does this tool work offline?

After the first visit, yes. The pdf-lib JavaScript library is cached by the browser on first load (about 380 KB minified). Subsequent visits to the page editor work without a network connection, as long as the browser cache has not been cleared in the meantime. The page-tree manipulation itself never needed the network in the first place; only the library load did. You can verify by enabling airplane mode after opening the page once and trying to delete or reorder a local PDF.

Can I delete or reorder pages from multiple PDFs at once?

Not directly: the UI accepts one source document at a time. The two-step workflow for multi-PDF edits is to use PDF Merge first to combine your sources into one document, then bring that combined PDF here to delete or reorder pages into the final sequence. 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 in one step. For batch automation across dozens or hundreds of files, the qpdf or pikepdf command-line tools are the right fit.

Should I edit pages before or after signing, flattening, or compressing?

The safe order is edit first, flatten next, sign after that, compress last. Edit first because subsequent operations depend on the final page sequence. Flatten next because it bakes form fields and annotations into static content so downstream tools handle the document uniformly. Sign after flatten because cryptographic signatures commit to the document's final byte sequence and any further change invalidates them. Compress last (optional) to reduce file size for transmission. Signed PDFs that are edited afterwards will fail signature verification in Acrobat and other signature-aware readers, so signing must always be the last content-touching step.

Will the OCR text layer be preserved on scanned pages?

Yes. OCR text in a PDF is stored as invisible text drawn over the scanned image (a content stream operator sequence marked invisible), and that content stream is part of the page object. When pdf-lib's copyPages copies a page, it copies the entire page object including all its content streams, font references, and any invisible OCR text layer. Search-and-select continues to work on the edited output exactly as it did on the original, for the pages that survived the edit. The text layer is bit-exact preserved; pdf-lib does not re-encode or re-rasterize anything.

Does deleting half the pages reduce the file size by half?

Usually less than half, sometimes much less. If the deleted pages had unique content (their own embedded images, their own font subsets), the savings are large. If the deleted pages shared resources with pages you kept (the same font used throughout, the same logo image on every page), the shared resources stay in the file. pdf-lib does not aggressively repack the file on save, so cross-page resource dedup that the original PDF already did is preserved but additional dedup opportunities created by the deletion are not exploited. For tight output run the result through PDF Compress, which does a full repack and an image re-encode and typically recovers the rest of the savings.

Is there a desktop or command-line equivalent for scripting?

Yes, several. pdf-lib runs unchanged in Node.js (npm install pdf-lib) and the editing code is identical: copyPages(source, indices) followed by addPage() for each. For the command line, qpdf has a per-page selection syntax: qpdf --pages input.pdf 1-4,6-20 -- input.pdf output.pdf keeps pages 1 through 4 and pages 6 through 20, deleting page 5. Python's pikepdf is a binding to qpdf with a cleaner API (del pdf.pages[2] to delete page 3, list-slicing semantics for reorder). Adobe Acrobat Pro provides the same operations through a GUI and additionally preserves bookmarks and the document outline across page mutations, which the browser-only path does not.

Related Tools

PDF Merger

Combine multiple PDFs into one file.

PDF Compressor

Reduce PDF file size while preserving quality.

Image Converter

Convert images between different formats.