Skip to content
Utilities2026-09-218 min read

The Complete Guide to PDF Tools: Merge, Split, Compress, and Convert — All in Your Browser

Why PDF Still Rules Documents

Fifty years into computing, the PDF remains the only format everyone's device opens identically. Contracts, government forms, scanned IDs, invoices — the business world runs on PDF because it guarantees what the sender sent is what the receiver sees. That fidelity, ironically, is also what makes PDFs painful: they are designed to be final, not to be edited, and the moment you need to merge two contracts, split a 40-page report, or slim a scanned application under a 2MB upload cap, you discover how hostile the format is to ordinary manipulation.

The usual escape hatch is an online PDF service. You upload the file, the server does the work, you download the result. For a restaurant menu, fine. For a signed contract, a passport scan, or anything with a bank account number in it, that upload is the moment your document leaves your control — you are trusting a company you found via search results with the contents of your most sensitive files, forever.

This guide walks through the four PDF operations everyone eventually needs, explains how each actually works under the hood, and shows how all four can run entirely in your browser with zero uploads — using the ToolVault PDF toolkit.

Merging PDFs: What Actually Happens

Merging sounds trivial — staple two files together — but the mechanics matter for what survives. A proper merge is structural: the tool copies the page objects from both PDFs into a new document without re-rendering anything. Text stays selectable, vectors stay sharp, file size stays the sum of its parts.

What can break in a merge:

  • Bookmarks pointing to page positions shift, because page numbers change.
  • Form fields with the same name across documents can collide.
  • Per-document security settings take the loosest policy in the result.
  • Scanned pages with rotation metadata usually carry over, but deserve a visual check.

The practical checklist before merging: confirm the order (list order becomes page order; use the arrows to reorder), unlock any password-protected files first (encrypted PDFs surface a clear error instead of silently producing blank pages), and — the classic mistake — make sure you did not drag in both the v1 and the v2 of the same document. The Merge PDF tool does structural merging in your browser, with no page limit and no upload; the download name defaults to the first file's base name (contract-merged.pdf) for easier filing.

Splitting PDFs: Three Different Goals

People say "split" for three different needs — and the split tool maps each to a mode:

  1. Extract a page range — pages 40-50 of a 200-page report for the meeting. The extract keeps content byte-identical to the source; nothing re-renders. Download names carry the range (report-p40-50.pdf).
  2. Burst into single pages — one invoice per file for forwarding individually. Output is a ZIP with zero-padded names (invoice-041.pdf) so file managers do not sort page-10 before page-2. You can burst only a sub-range when you do not need the whole book.
  3. Chunk by page count — an email attachment limit of 10MB versus a 26MB scan. The tool slices into N-page PDFs and zips them. For hard megabyte caps, compress first, then chunk: structural slicing does not shrink per-page bitmaps; compression does.

A detail worth knowing: if the original document has printed page numbers in its content layer, an extract of pages 40-50 keeps the original numbering (page 40 still says "40"), which is usually what you want for references but surprises people expecting a renumbered document. The Split PDF tool handles all three patterns locally.

How PDF Compression Really Works

Compression is where the most misunderstanding lives. A PDF is a container; its size comes from what is inside. Three broad profiles:

Scanned/image PDFs — every page is one big raster image, typically 300 DPI. These are the compression goldmine: re-rendering pages as JPEG at quality 50-65 routinely cuts 60-90% of the size with no perceptible loss, because the original scan carries far more resolution than screen or print consumption needs. This is why the 40MB scanned contract becomes a 4MB file that looks identical.

Vector/text PDFs — generated by Word, LaTeX, report tools. Already tiny per page. Re-rendering these increases size, because you are converting efficient vector text into raster images. A good compressor detects this and honestly reports the growth instead of pretending to help; when it does, the right moves are deleting redundant pages or splitting, not compressing.

Mixed PDFs — a report with embedded charts and photos. Compression helps roughly in proportion to the raster share.

The tell before you even try: a file over 5MB with few pages is almost certainly scan-heavy — compress freely. A 40-page file at 300KB is vector — do not bother. And the lossy caveat: compression softens text edges slightly, so legal archives that demand bit-exact preservation should split rather than compress. The Compress PDF tool shows before/after sizes (including +x% when the file grew) and processes everything on-device — which, for the contracts this operation usually involves, is the entire point.

PDF to JPG: When You Need Pages as Images

Converting pages to images serves three real purposes: presentation material (slides reuse, embedding in docs), social sharing where PDF viewers do not exist, and visual reference when text selection does not matter.

The trade you are making: text becomes pixels. A converted page can no longer be searched, copied, or read by screen readers — if any of those matter, what you need is not conversion but a PDF reader. Quality-wise, output sharpness is bounded by the source: pages from 300 DPI scans extract beautifully; 72 DPI screen captures stay soft no matter what. For text-heavy pages, PNG output beats JPG — compression artifacts appear first around small letters.

You do not have to render the whole book: set a from/to page range to export only what you need and keep memory under control on large documents. Output is a ZIP with filenames zero-padded against the full page count (exporting pages 40-50 still yields doc-040.jpg). The PDF to JPG tool renders page by page in the browser.

The Reverse Direction: Photos to PDF

The everyday version of this need: photograph a stack of receipts or ID copies on your phone, then send them as one civilized document instead of eleven images in random order.

Two things worth knowing. First, when images enter a PDF they embed without re-encoding — ten 4MB photos produce a roughly 40MB PDF, so compress images first if the destination caps size. Second, chat apps re-compress images sent as photos but transmit PDFs as files; wrapping photos in a PDF is a quality preservation trick, not just an organizing one. The JPG to PDF tool keeps page order exactly as arranged and runs locally — the relevant property when the photos are of your passport.

Why "Local" Is Not a Marketing Word

Every operation above runs in your browser: the file is read by JavaScript, processed in memory, and written back to your download folder. No server receives a byte. You can verify this yourself in any of the linked tools — open DevTools, watch the Network panel, and confirm zero outbound requests while you work.

For PDFs specifically, this matters more than for most file types, because the documents that trigger PDF operations disproportionately are the sensitive ones: contracts under negotiation, visa applications, medical records, financial statements. The step between "I need to merge these two files" and "I have now uploaded my signed contract to a random web service" should not be automatic. Browser-local processing makes that step disappear rather than asking you to trust anyone.

Capability Boundaries (Avoid the Common Traps)

BoundaryWhat to do
Password-protected PDFUnlock and re-save in a reader first; the tools refuse encrypted files instead of emitting blank pages
Huge page counts / memorySplit and PDF→JPG both accept page ranges — do not rasterize hundreds of pages in one go
Hard size caps (10MB email)Compress scans first, then chunk by page count; text-only vector PDFs may grow when compressed
Need searchable textUse merge/split (structural); PDF→JPG and compress (rasterize) discard the text layer
Non-contiguous pages (3 and 10)Extract twice, then merge the pieces

Quick Reference: Which Tool When

SituationToolKey property
Contract + attachments → one fileMerge PDFStructural, no re-render
Extract report pages 40-50Split PDF · rangeByte-identical extract
One invoice file per pageSplit PDF · burstZero-padded ZIP
Scan must fit an attachment limitCompress → chunk by pagesShrink, then slice
Pages needed as imagesPDF to JPGOptional range + padded ZIP
Phone photos → one documentJPG to PDFNo re-encoding, order preserved

All five accept files via drag-and-drop, process them in your browser, and forget them the moment you close the tab. That last part is a feature.

Triage notes

The compression section sorts files into three profiles before talking principles, because the payoff depends entirely on what the container holds: scanned files are the compression goldmine (re-rendering as JPEG routinely cuts 60-90%), while vector-text files can come out larger — a good compressor reports the growth honestly instead of pretending to help, and the right action then is splitting or deleting pages. The before-you-start test fits in one sentence: over 5MB with few pages is almost certainly scanned, compress with confidence; 40 pages at 300KB is vector, do not bother. The 'Local is not a marketing word' section offers an acceptance test you can run yourself — open DevTools, watch the Network panel, confirm zero outbound requests during the operation — because the documents that trigger PDF work are disproportionately sensitive.

Provided by ToolVault — 166 developer tools, all browser-local.