PDF Workflow Guide

Why the Order You Process PDFs Matters More Than the Tools You Use

A paralegal is preparing a 45-page contract for client delivery. She runs it through a compressor first: 12MB down to 4MB, a solid result. Then she notices pages 31 through 35 are from an outdated version. She splits those pages out, replaces them with the correct five pages from a separate file using a merger, and ends up with a corrected 40-page document that is now back up to 11MB because the newly merged pages arrived uncompressed. She compresses again, gets it back to 4.1MB, then adds a "CONFIDENTIAL" watermark, then applies password protection. Four tool operations became seven, and two of them were pure repetition of work she had already done.

The right order for the same task: merge all source documents first, split out the wrong pages and replace them before any optimization happens, compress the final assembled 40-page document once, apply the watermark, then apply password protection. Same outcome, three fewer operations, and the compression runs once on the finished content rather than twice on different versions of an incomplete document.

The logic behind this sequence is structural. Each operation acts on a different layer of the document, and later operations need earlier layers to be stable before they can do their work properly. Merging and splitting change the page structure: the fundamental question of which pages exist in the file. Every subsequent operation applies to exactly the pages that survive this stage, so structure must be finalized first. Compression reduces file size based on the current content of those pages, so doing it early means compressing pages you may remove, then adding uncompressed pages later. Watermarking modifies the visual layer of each page by adding rendered overlay elements. Password protection encrypts the entire content layer, so it belongs last because an encrypted file cannot be modified without the decryption credential.

Structure first. Then optimize. Then secure. Every step builds on a stable foundation from the previous one.

What Actually Happens Inside a PDF During Each Operation

Merging. A PDF file is an object graph. Every text block, image, font definition, annotation, and page reference is a numbered object stored in the file body. The cross-reference table maps each object number to its byte offset within the file, which is how the PDF reader finds anything without parsing the entire file sequentially. When you merge two PDFs, the merger reads both cross-reference tables, renumbers the objects from the second file to avoid collisions with the first file's numbering, combines both page trees into a single parent page tree, and writes a new unified cross-reference table. The result is a single file containing all objects from both sources.

Font handling during merging creates an important inefficiency: if both source files use the same font, such as Arial for body text, the merged file may contain two copies of that font's embedded data rather than one shared copy. This is why merged files are commonly larger than the sum of their sources. A professional merger can detect and deduplicate identical embedded fonts, but most browser-based tools prioritize correctness over this optimization. Expect 5 to 15% overhead in merged files compared to the sum of source file sizes.

Splitting. The splitter reads the cross-reference table, identifies every object referenced by the selected page or page range, copies those objects into a new file with a fresh cross-reference table, and writes the result. That includes the page content stream, embedded images, font definitions, color profiles, annotations, and form fields. Objects shared across multiple pages, such as font definitions used throughout the document, are included in the split output even if most of the pages using them were left behind. A 10-page split from a 100-page document is not one-tenth the file size. The split output carries every shared resource necessary to render its pages correctly.

Compression. PDF compression targets four distinct categories of data, each with different reduction potential. Images are almost always the dominant file size contributor, particularly in scanned documents where every page is a full-resolution raster image. A scanned contract page captured at 300 DPI is typically 2 to 3MB per page as an uncompressed image. Downsampling to 150 DPI for screen viewing reduces that to approximately 500KB per page, a 75% reduction with minimal visible difference on a monitor or standard office printer. At 96 DPI for web or email viewing, the same page reaches 200KB. Compression tools target the resolution and JPEG quality level of each embedded image independently.

Content streams, the text rendering instructions that draw characters at specific positions with specific sizes and colors, are compressed using Flate encoding. These are already space-efficient for typical business documents and rarely account for more than 5 to 10% of file size in mixed text-and-image files. Font subsetting is more impactful: a PDF may embed the complete font file for every font used, even if the document uses only a fraction of the glyphs. A complete Arial font file is approximately 400 to 600KB. If the document only uses Latin characters and basic punctuation, subsetting can replace the full font with a smaller glyph subset, reducing that font's contribution to roughly 40 to 60KB. Metadata and document history rarely account for more than a few KB and are the least impactful compression target.

Realistic compression results vary sharply by document type. A 50-page text-only contract that starts at 800KB may compress to 650KB, only an 18% reduction, because text streams and fonts are already compact. A 20-page scanned document at 300 DPI can drop from 35MB to 8MB, a 77% reduction, because image downsampling delivers the savings. A 30-slide presentation export with embedded graphics commonly drops from 15MB to 5MB. A 10-page form-heavy document might move from 2MB to 1.5MB, mostly through font subsetting and form field cleanup.

Password protection. PDF encryption applies AES-256 to the file's content streams: the text and image data that constitutes the readable document. Two distinct passwords serve different access levels. The user password, when set, must be entered before the file opens at all. The owner password controls document permissions: whether the recipient can print, copy text, extract pages, or make annotations. A document with only a user password grants full permissions to anyone who enters that password. A document with both passwords restricts the user-password holder to whatever permissions the owner set, while the owner-password holder retains full control.

Browser-Based PDF Processing vs Cloud Services: The Privacy Question

When you upload a file to Adobe Acrobat Online, iLovePDF, SmallPDF, or any other cloud PDF service, the complete file transmits to their server over HTTPS, is decrypted on their infrastructure for processing, and the result is transmitted back. The file exists on their hardware for some duration, typically one to 24 hours based on stated retention policies, though policy and practice are not always auditable from the outside. The HTTPS encryption protects the file in transit but does not protect it during the processing window on their server.

This is an acceptable trade for publicly available marketing materials, published reports, or any document you would be comfortable distributing freely. It is a meaningful privacy question for contracts, medical records, financial statements, personnel files, legal discovery documents, or any file that is confidential by nature or by the terms of an NDA. If you would not send the file to an unknown person by email, the same logic applies to uploading it to a processing server operated by a company whose full data handling practices you cannot verify.

Browser-based processing eliminates server involvement entirely. Tools like Tooliest's PDF suite use JavaScript libraries, including PDF-lib for merging, splitting, and password operations, that execute within your browser tab. The file is read from your device into the browser's memory, processed by JavaScript running on your CPU, and the result is written back to your device. No data is transmitted. No server receives the file. No retention policy applies because no third party ever touches the content.

The practical tradeoff is processing speed on very large files. Your browser operates within memory and CPU constraints that a cloud server with dedicated processing hardware does not share. For files under approximately 50MB and documents under 200 pages, which covers the vast majority of daily professional PDF work, browser-based processing is fast enough that the difference is not noticeable. For a 200-page scanned document at 300 DPI totaling 400MB, a cloud service may be meaningfully faster. For files in that size range, the decision should be made consciously based on content sensitivity rather than defaulting to whichever tool opens first.

Cloud tools also hold an advantage for optical character recognition, which requires inference models too large to run in a browser at acceptable speed, and for automated batch processing through APIs. For any task that falls outside those two cases, browser-based processing provides equivalent functionality with a privacy profile that cloud services cannot match.

Four PDF Workflows for Common Professional Tasks

The sales kit result is a single professional document, appropriately compressed for email delivery within the 25MB attachment limit most corporate email servers enforce, watermarked to communicate its status, and optionally locked for recipients who need the pricing but not the ability to extract and redistribute it.

The onboarding packet result is cleaner for both sides: employees receive one comprehensive packet instead of six separate attachments that can arrive in the wrong order, while HR gets a return-focused version that clarifies exactly which signed documents should come back.

The confidential report workflow protects both access and behavior. Board members can open the file with the user password and view content normally, but copy, extraction, print, and edit permissions can stay restricted behind the owner credential. The watermark visually communicates confidentiality even if the file is displayed on a shared screen.

The archive bundle turns a messy folder of scattered PDFs into one file with a stable order, smaller storage footprint, page-level citation support, and access control over its retention lifetime. That structure matters months later when someone needs to find a specific approval or invoice without reconstructing the project history from filenames.

Build your next PDF workflow using Tooliest's browser-based tools: merge documents with the PDF Merger, extract pages with the PDF Splitter, reduce file size with the PDF Compressor, stamp pages with the PDF Watermark tool, and lock sensitive files with PDF Password Protect. Every operation happens in your browser, so your documents never leave your device.