Tag: PDF

  • PDF Merger Tool: Combine PDFs in Your Browser [2026 Guide]

    PDF Merger Tool: Combine PDFs in Your Browser [2026 Guide]

    TL;DR: A PDF merger tool combines multiple PDF files into one, in the order you choose. Our browser-based PDF merger drops, reorders, and merges entirely on your device — no upload, no signup, no file size cap. Text stays searchable, fonts stay embedded, and the merged file is structurally identical to running pdftk cat from the command line. For most office workflows (contract packages, signed-document stacks, multi-source reports), this is the fastest workflow you can build.

    Every office worker hits the same wall once or twice a month: the contract is in two PDFs, the signature page is in a third, the appendix arrived as a separate email attachment, and the recipient wants one file. PDF merging is the mundane plumbing of business workflows — boring, frequent, and easier with the right tool than people realise. The catch is that the most popular cloud-based mergers upload your file to their servers, which is the wrong default for contracts, signed documents, medical records, or anything containing PII.

    Our PDF merger tool runs entirely in your browser using pdf-lib — the same JavaScript PDF library that powers many enterprise document pipelines. Drop your PDFs, reorder them with arrow buttons, click merge. The output downloads to your device. Nothing transmits. This guide explains how PDF merging actually works under the hood, what gets preserved vs lost during the merge, and the workflow tricks that make merging fast for repeat tasks.

    What does PDF merging actually do to the file?

    A PDF is a tree of objects — pages, fonts, images, metadata, structural elements — referenced by a cross-reference table. Merging two PDFs concatenates the page lists from each source while copying every referenced object (fonts, images, etc.) into the output’s object table. The result is a single PDF whose pages appear in the order you specified, with no quality loss because no pixel data is recompressed.

    Element What happens during merge
    Pages Concatenated in your specified order. No re-rendering.
    Text content Fully preserved. Searchable, selectable, and copy-pasteable in the merged file.
    Fonts Embedded fonts from each source are copied. If the same font appears in multiple sources, it’s deduplicated.
    Images Preserved at original quality. No recompression.
    Hyperlinks Preserved per-page. Internal links that pointed within the original PDF still work.
    Bookmarks / TOC Most browser-based mergers strip these. Heavyweight tools (Acrobat, PDFsam) preserve and renumber.
    Form fields Preserved. If two PDFs have fields with the same name, behavior is undefined — rename in source first.
    Digital signatures Invalidated. Signatures cryptographically sign the entire file’s bytes; merging changes those bytes.
    Metadata (title, author, etc.) Inherited from the first PDF in the list, or blank if our tool’s metadata-strip default is on.

    The signature gotcha matters for legal workflows. If you’re merging a digitally-signed contract with an appendix, the merged file no longer carries the signature’s cryptographic validation — opening it in Acrobat shows the signature as “invalid” because the document hash has changed. Workflow: merge first, then sign the combined file, or keep signed documents separate and bundle them in a ZIP.

    The five workflows people actually use a PDF merger for

    • Contract package assembly. NDA + master agreement + statement of work + signature page = one deliverable. Reorder so the cover page is first, signature page last. The most common business use case.
    • Receipts and expense reports. Combine 12 individual receipt PDFs into a single end-of-quarter expenses document. Saves the 12-attachment email and gives accounting one file to file.
    • Multi-source research bundle. Three articles, two slide decks exported as PDF, one transcript — one master read-pack for the team. Order matters here: put the executive summary first.
    • Email + attachments archive. Many email clients let you “print to PDF” both the message and its attachments. Merging produces a single permanent record. Useful for legal discovery and personal archiving.
    • Scanned document stacking. A scanner that produces one PDF per page (still common in older office machines) leaves you with 30 single-page PDFs after a long scan job. Merge produces the document you actually wanted.

    For each use case, the order of the source PDFs matters. Spend a moment with the up/down arrows before clicking merge — fixing order after the fact requires splitting + remerging, which is more work than getting it right the first time.

    How to use the browser PDF merger

    1. Open the PDF merger tool
    2. Drop your PDFs onto the dropzone, or click to pick files. Multiple selection works on every modern OS
    3. Each file appears in a list with its filename and page count
    4. Use the up / down arrow buttons to reorder. The order in the list is the order in the merged output
    5. Trash icon removes any file you don’t want included
    6. The total page count for the merged file shows above the list — sanity-check before merging
    7. Click Merge. The merged PDF downloads as merged-{timestamp}.pdf

    Everything happens locally — when you select a file, the browser reads it, parses the page count, and discards it from memory after merge. No copy is sent to our servers. The 100MB+ practical ceiling is your browser’s RAM, not a server-side cap. Most laptops handle hundreds of source PDFs at a time without issue.

    Cloud merger vs browser merger — the privacy trade-off

    The PDF merger market is split between cloud-based services (iLovePDF, Smallpdf, Adobe Acrobat online) that upload your file to their servers and process it there, and browser-based tools (ours, Drawboard, PDFsam in its desktop form) that process locally. The trade-off:

      Cloud merger Browser merger
    Speed Fast for huge files (server CPU) Limited by your device
    File size limit 10-50MB typical free tier Limited by browser RAM (~200-500MB)
    Bookmark preservation Usually yes Usually no (pdf-lib doesn’t preserve)
    Privacy File uploaded, retained briefly per privacy policy Never leaves your device
    Internet required? Yes, for entire operation Only for first page load
    Right for Public PDFs, marketing assets Contracts, medical, legal, anything sensitive

    For an offsite training PDF you’re combining with the public schedule, cloud is fine. For a draft NDA being merged with a tax return for a property purchase, never upload — privacy isn’t a policy promise on a help page; it’s the architecture of where the bytes go. Browser-based merging gives you architectural privacy.

    Merging PDFs in code

    For automated pipelines — say, monthly receipt-bundle generation or batch document assembly — a script beats clicking. Each environment has a mature library.

    Python (pikepdf — fastest, lossless):

    import pikepdf
    from pathlib import Path
    
    merged = pikepdf.Pdf.new()
    for path in sorted(Path("inputs").glob("*.pdf")):
        src = pikepdf.Pdf.open(path)
        merged.pages.extend(src.pages)
    merged.save("merged.pdf")

    Node.js (pdf-lib — the same library our browser tool uses):

    import { PDFDocument } from "pdf-lib";
    import { readFile, writeFile } from "node:fs/promises";
    
    const merged = await PDFDocument.create();
    for (const file of ["a.pdf", "b.pdf", "c.pdf"]) {
      const bytes = await readFile(file);
      const src = await PDFDocument.load(bytes);
      const pages = await merged.copyPages(src, src.getPageIndices());
      pages.forEach((p) => merged.addPage(p));
    }
    await writeFile("merged.pdf", await merged.save());

    qpdf (CLI — fastest for very large jobs):

    # Merge in alphabetical order
    qpdf --empty --pages *.pdf -- merged.pdf
    
    # Merge specific files in specific order
    qpdf --empty --pages a.pdf b.pdf c.pdf -- merged.pdf
    
    # Preserve bookmarks (qpdf does this by default; some libraries don't)
    qpdf --empty --pages a.pdf 1-5 b.pdf 1-z -- merged.pdf

    Ghostscript (CLI — slowest but recompresses + may shrink output):

    gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite \
       -sOutputFile=merged.pdf a.pdf b.pdf c.pdf

    Choose by goal. pikepdf and pdf-lib are lossless and fast — same approach as our browser tool. qpdf is the most powerful for complex page-range merges and preserves bookmarks. Ghostscript re-encodes everything (slower but can produce smaller files because it consolidates duplicated objects across sources). For most workflows, pikepdf or pdf-lib is the right answer.

    Merging password-protected PDFs

    Browser-based mergers can’t read encrypted PDFs without the password — pdf-lib loads encrypted documents only if you pass the password explicitly, and our tool doesn’t expose that field by design. Three options when one of your sources is password-protected:

    • Decrypt first, merge second. Open the encrypted PDF in Adobe Acrobat (or qpdf with --decrypt), save an unencrypted copy with a different filename, then merge. Delete the unencrypted copy after the merge if the password protected sensitive content. Don’t share the unencrypted intermediate file.
    • Use qpdf at the command line. qpdf --password=secret --decrypt encrypted.pdf decrypted.pdf, then merge with the steps above. Direct enough that the password never leaves your terminal session.
    • Skip the encrypted source. If the encryption is meaningful (PII, financial data), think hard before merging — a single combined unencrypted file is now your weakest-link risk. Consider keeping the documents separate and bundling them in a password-protected ZIP instead.

    Common mistakes that produce bad merges

    • Wrong page order. The list order in the tool is the merge order. Always sanity-check the order before clicking merge — fixing it post-merge requires splitting and remerging.
    • Mixing landscape and portrait pages without thinking. The merged PDF will display them in their original orientations, which can read as inconsistent. Either rotate problem pages first (some PDF tools have a rotate option, or use qpdf --rotate) or accept the mixed orientation if it’s fine for your reader.
    • Merging across versions of the same document. If you have v1 and v3 of a contract and accidentally merge both, the result is two confusingly-similar copies. Always rename or archive old versions before assembling a deliverable.
    • Forgetting that signed PDFs lose signatures on merge. Sign the merged file, not the components, when you need a single legally-binding document.
    • Merging huge files all at once on a low-memory device. 50 source PDFs at 20 MB each requires 1 GB of free browser RAM minimum. If your device is tight, merge in batches (10 PDFs first, then 10 more, etc.) rather than all at once.

    When NOT to merge PDFs

    • Legal exhibits. Court filings often require each exhibit to remain a separate file with its original filename. Merging changes the file’s identity for evidence purposes. Check the local rules before combining.
    • Already-digitally-signed contracts. Merging invalidates the signature. If the signature is the whole point of the document, keep it separate.
    • Different access-control documents. A confidential financial statement merged with a public marketing PDF inherits the most-permissive distribution permissions automatically. Keep different sensitivity levels separate.
    • Documents whose order changes by audience. If you sometimes need the appendix first and sometimes last, keep the parts separate and merge fresh per audience.
    • Files that exceed 100MB total. Browser memory becomes the bottleneck. Use qpdf or pikepdf locally instead.

    Frequently asked questions

    Does merging PDFs reduce their quality?

    No. PDF merging copies pages and embedded resources without re-encoding any content. The merged file is byte-for-byte equivalent to the source pages — text stays searchable and selectable, images retain their original quality, fonts render the same. The only thing that changes is the file’s metadata and structural elements (cross-reference table, object IDs).

    Is there a limit on how many PDFs I can merge?

    The browser tool’s limit is your device’s RAM, not a fixed file count. Merging 50 small office PDFs is trivial; merging 50 image-heavy 20MB PDFs needs about 1 GB of free browser memory. For very large jobs (hundreds of PDFs, gigabytes of total size), use a command-line tool like qpdf or pikepdf locally, which streams the merge rather than loading everything into memory.

    Will the merged PDF be searchable?

    Yes — text content, hyperlinks, and form fields all survive merging. If a source PDF was searchable before, those pages are searchable in the merged output. If a source was a scanned image-only PDF without OCR, those pages remain image-only in the merge. To make scanned pages searchable, run OCR (Adobe Acrobat, tesseract, ABBYY FineReader) before or after merging.

    Are bookmarks preserved when I merge?

    In our browser tool, no — pdf-lib (the underlying library) doesn’t preserve bookmarks across merges. If your workflow needs combined bookmarks (think long technical reports with TOCs), use Adobe Acrobat, PDFsam Basic, or qpdf at the command line — all three preserve and renumber bookmarks during merge.

    Can I merge a PDF with a Word document or image?

    Not directly. PDF mergers only accept PDF input. Convert other formats first: print Word documents to PDF (built into Word and Google Docs), or use an image-to-PDF tool to wrap photos and scans into PDF format. Then merge as usual.

    Is my PDF uploaded when I use the merger?

    No. The browser reads your PDF locally via the File API, parses it with pdf-lib, performs the merge in JavaScript, and offers the result as a download — all without making any network requests. Verify by opening Chrome DevTools → Network tab and watching for upload requests when you click merge: there are none.

    Related tools and guides

     

  • Free PDF Compressor: Reduce PDF Size in Your Browser [2026]

    Free PDF Compressor: Reduce PDF Size in Your Browser [2026]

    TL;DR: A free PDF compressor reduces file size by stripping embedded metadata, recompressing the document structure, and (in heavyweight tools) recompressing or downsampling embedded images. Our browser-based PDF compressor handles structural compression entirely on your device — no upload, no signup. Typical savings are 15-50% on PDFs with metadata bloat. For image-heavy PDFs needing 70-90% savings, you’ll need image recompression too.

    The single most common reason people search for a free PDF compressor: they’re trying to attach a contract, invoice, or scan to an email and Gmail rejects anything over 25 MB, Outlook over 20 MB, corporate mail servers often over 10 MB. The PDF that came out of Word at 18 MB suddenly needs to be under 10 MB by Tuesday. That’s the workflow.

    Our PDF compressor handles the structural side of the problem entirely in your browser using pdf-lib — no upload, no signup, no third party seeing your contracts. This guide explains the two distinct kinds of PDF compression (and which one you actually need), the metadata most PDFs leak about you without you knowing, the size-vs-quality math for image-heavy documents, and the command-line tools to reach for when browser compression isn’t enough.

    The two kinds of PDF compression — pick the right one

    Most “free PDF compressor” tools blur the distinction, which is why people sometimes get 5% savings when they expected 80%, or vice versa. The honest version: there are two fundamentally different operations both called “compression”.

    Approach Typical savings Quality cost When to reach for it
    Structural compression (metadata strip + object streams) 5-30%, occasionally 50% on bloated PDFs None — fully lossless. Text searchability preserved. Office documents, contracts, forms, anything text-heavy
    Image recompression (downsample + re-encode embedded images) 50-90% on image-heavy PDFs Visible. Photos lose detail; scans get JPEG artefacts. Scanned documents, photo-heavy reports, magazines

    Our browser tool does the first kind. The second kind requires either heavy server-side libraries (Ghostscript, Adobe Acrobat) or specialised WebAssembly bundles that take 10-30 seconds per MB to run client-side. We made the deliberate trade-off to keep the browser tool fast and lossless rather than slow and lossy.

    How to know which kind you need. Open your PDF in any viewer. If you see large embedded photos, screenshots, or scanned pages, you need image recompression. If it’s mostly text — contracts, invoices, generated reports, forms — structural compression often gets you the savings you need with no quality loss at all.

    What metadata is your PDF leaking?

    The under-appreciated reason to compress a PDF before sharing: the metadata it carries by default. Every PDF generator embeds a surprising amount of detail about how the file was created, often including data the original author didn’t realise was attached. Stripping metadata is part of structural compression and produces both privacy benefits and modest size savings.

    • Author name. Microsoft Word and Google Docs default to using your account name. Send a contract to a counterparty and they see exactly which employee at your company drafted it.
    • Software and version. “Microsoft® Word for Microsoft 365 MSO (Version 2401)” tells anyone who opens the file what software you use and roughly when you upgraded. Useful info for social engineering.
    • Creation and modification timestamps. Down to the second, in the PDF object dictionary. Lawyers occasionally use these to challenge document authenticity.
    • Original filename. Even if you renamed the PDF for sending, the original filename often persists in the metadata. tax-return-final-FOR-REAL-this-time-v7.pdf on the inside.
    • Hidden tracked changes (in old PDFs). Word’s Track Changes data can survive an export to PDF if the export uses the wrong settings. Less common in 2026 than it was, but still happens.

    Our compressor strips title, author, subject, keywords, producer, and creator fields by default. The exiftool / qpdf check after compression returns clean results — no leaked author or software identifiers. For high-stakes documents (contracts being sent to opposing counsel, public-records releases, journalism source documents), this is the cheapest privacy-protection step you can take.

    How to use the browser PDF compressor

    1. Open the PDF compressor
    2. Drop your PDF (up to 100 MB) into the dropzone, or click to pick a file
    3. The tool reads the file size and page count locally — nothing uploads
    4. Choose options:
      • Strip metadata — recommended on; removes title, author, subject, keywords, software identifier
      • Use object streams — recommended on; PDF 1.5+ feature that compresses the document structure
    5. Click Compress. The output appears with a percentage savings indicator
    6. Click Download to save the compressed PDF locally

    Compression takes 1-3 seconds for typical office PDFs (2-20 MB). For larger files (50-100 MB), it can take 10-15 seconds because pdf-lib has to parse and re-serialise the entire document. Browser RAM usage peaks at roughly 3-4× the file size during compression — a 100 MB PDF needs about 350 MB of free browser memory to process.

    How much can you actually save?

    Real numbers from a sample of common PDF types we tested:

    PDF type Typical structural-compression savings Notes
    Word-generated contract or report 15-30% Lots of structural overhead from Word’s PDF export
    Google Docs export 5-15% Already reasonably efficient
    LaTeX / Pandoc output 2-8% Already near-optimal; little structural waste
    Filled-out PDF form (filled via Acrobat) 10-25% Form-state metadata strips well
    Scanned multi-page document 2-5% Bottleneck is image data, not structure — use image recompression
    Photo-heavy magazine/portfolio 3-8% Same — needs image-side compression for real savings
    Bloated PDF with embedded fonts not subset 30-60% Some legacy software embeds full font files instead of subsetting them

    The savings number on the tool isn’t a marketing claim — it’s the actual difference between input and output bytes for your specific file. If the savings come back at 5%, that’s because your PDF was already efficient; the tool isn’t doing nothing, there’s just nothing more to compress structurally.

    For image-heavy PDFs that need 70-90% savings

    If your PDF is a scanned document or contains many embedded photos, structural compression alone won’t get the file under your email size limit. You need image recompression — which means downsampling and re-encoding the embedded images. Our browser tool doesn’t do this, but the standard approaches all work well.

    Ghostscript (CLI, macOS / Linux / Windows):

    # Basic compression with sensible defaults
    gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 \
       -dPDFSETTINGS=/ebook \
       -dNOPAUSE -dQUIET -dBATCH \
       -sOutputFile=output.pdf input.pdf
    
    # Quality presets:
    #   /screen   = 72 dpi  — heaviest compression, screen-quality
    #   /ebook    = 150 dpi — good balance for email + screen
    #   /printer  = 300 dpi — print-quality, modest compression
    #   /prepress = 300 dpi — print-quality, color-managed

    Python (pikepdf + Pillow for image recompression):

    import pikepdf
    from io import BytesIO
    from PIL import Image
    
    pdf = pikepdf.open("input.pdf")
    for page in pdf.pages:
        for name, raw in page.images.items():
            pdf_image = pikepdf.PdfImage(raw)
            pil = pdf_image.as_pil_image()
            # Downsample if larger than 1500px
            if max(pil.size) > 1500:
                pil.thumbnail((1500, 1500))
            buf = BytesIO()
            pil.save(buf, format="JPEG", quality=80, optimize=True)
            page.images[name] = pikepdf.unparse(
                pikepdf.Stream(pdf, buf.getvalue()))
    pdf.save("output.pdf")

    qpdf (CLI, lossless structural only — equivalent to our browser tool):

    qpdf --object-streams=generate --remove-page-labels \
         --linearize input.pdf output.pdf

    For most office workflows, Ghostscript with the /ebook preset is the right starting point — it downsamples to 150 DPI (sufficient for screen viewing and most printing) and re-encodes images at JPEG quality 75. Real savings are typically 60-85% on scanned PDFs.

    The DPI and quality decisions that drive image compression

    If you’re using Ghostscript or any image-recompression tool, the two knobs that matter most:

    • Image DPI (dots per inch). Photos and scans inside PDFs are stored at a specific resolution. Web/screen viewing only needs 72-150 DPI — anything above is invisible at typical display sizes. Print needs 300 DPI for crisp output. Most “bloated” PDFs are stored at 600 DPI or higher because that’s whatever the camera/scanner produced. Downsampling to 150 DPI typically halves the file size with no visible quality loss on screen.
    • JPEG quality (0-100). The size-vs-quality knob for photo recompression. Quality 85-90 is visually indistinguishable from the original; quality 70-80 has slight artefacts visible only side-by-side; quality 50-60 has visible compression but is acceptable for thumbnails or previews. Our recommendation: 80 for general use, 70 if email size is the dominant constraint.

    The non-obvious choice: JBIG2 for black-and-white scans. If your PDF is purely scanned text or line drawings (no colour, no greyscale photos), the JBIG2 compression algorithm produces files 5-10× smaller than JPEG at equivalent visual quality. It’s the algorithm scanners use for archival document compression. Acrobat’s PDF/A export and Ghostscript’s -dPDFSETTINGS=/ebook on monochrome content both use JBIG2 automatically.

    The “compress before email” workflow that saves your day

    Email file-size limits in 2026:

    • Gmail: 25 MB attachment limit. Anything larger triggers a Google Drive link.
    • Outlook (Microsoft 365): 20 MB by default; admin can raise to 150 MB.
    • Outlook (Outlook.com personal): 33 MB.
    • Corporate mail servers (Exchange): commonly 10 MB, sometimes 25 MB. Rejection without warning is the usual failure mode.
    • Apple Mail (iCloud): 20 MB; Mail Drop kicks in for larger files.
    • WhatsApp Business / SMS attachments: 100 MB on WhatsApp; SMS varies wildly by carrier.

    The pragmatic rule: target under 10 MB for any PDF you send to a counterparty whose mail server you don’t know. Almost all corporate Exchange servers accept files at this size. If structural compression alone doesn’t get you there, the next step is splitting the PDF (use our PDF splitter) or running Ghostscript locally for image recompression.

    Privacy: why local PDF compression matters more than you think

    The PDFs people most often need to compress are exactly the ones they shouldn’t upload to a third party: signed contracts, scanned ID documents for visa applications, medical lab results, tax returns, employee onboarding forms, legal exhibits. The major cloud-based PDF services (Smallpdf, iLovePDF, Adobe Acrobat online) all process your file on their servers — they’re trustworthy companies, but every upload is a fresh risk.

    • What the upload-based services typically log: filename, file size, source IP, processing duration, account info if signed in. Some retain the file briefly (24 hours is common) for processing redundancy.
    • What can go wrong: rare but real — service breaches, employee misconduct, government data requests, accidental URL leaks of processed files. Smallpdf’s privacy policy explicitly notes “we may share with law enforcement when legally required”.
    • What browser-only compression eliminates: all of the above. The file never leaves your device. There’s no log, no IP record, no retention, no breach exposure. The privacy guarantee is architectural, not a policy promise.

    For most casual PDFs (a meeting agenda, a public PDF you found online), upload-based compression is fine. For anything containing PII, contracts, or confidential information, the browser-based path is the right choice — even if you have to accept smaller savings than the cloud tools claim.

    Common mistakes that produce bad PDF compression

    • Compressing twice. Running the same PDF through three different “compressors” produces diminishing returns and can occasionally damage embedded fonts. Stop after one compression pass, evaluate the savings, and switch tools (or accept the result) rather than re-running.
    • Using /screen Ghostscript preset for print materials. Downsamples to 72 DPI and produces visible pixelation on print. Use /ebook (150 DPI) for general purpose and /printer (300 DPI) for anything that’ll go on paper.
    • Compressing OCR’d scans aggressively. Heavy JPEG compression on scanned text breaks OCR accuracy — characters lose their crisp edges and machine-readable layer underneath the visual layer can desync. Use JBIG2 for black-and-white scans and stay above quality 80 for greyscale.
    • Forgetting to subset embedded fonts. Modern PDF generators subset fonts (embed only the characters used) but legacy or open-source tools sometimes embed entire font files. A PDF with three fully-embedded TrueType fonts can be 30-60% larger than the same PDF with subsetted fonts.
    • Compressing already-compressed PDFs. A PDF saved with Acrobat’s “Reduce File Size” once already has structural compression baked in. Running it through another structural compressor produces 1-3% additional savings at most. Use image recompression instead.

    When NOT to compress a PDF

    • Legal exhibits and court filings. Many jurisdictions require unmodified original PDFs for evidence purposes. Compression changes the file’s hash and metadata, which can be challenged in court. Submit originals; if size is a problem, ask the court for permission.
    • PDFs with digital signatures. Compressing a signed PDF invalidates the cryptographic signature. The signed file becomes unverifiable. Compress before signing, never after.
    • PDFs being archived for long-term preservation. Archival formats (PDF/A) are designed to maximise long-term readability, including embedded fonts and full-quality images. Compressing strips exactly the elements that make archival reliable.
    • Already-tiny PDFs. A 200 KB email confirmation has no meaningful compression headroom. Skip the step.
    • When you need editability later. If you’ll re-open the PDF in Word or Google Docs to edit, certain compression settings degrade the OCR accuracy needed for clean re-export.

    Frequently asked questions

    Why is my compressed PDF only 5% smaller?

    You’re hitting the structural-compression ceiling. PDFs generated by modern software (Google Docs, recent Word, LaTeX) are already structurally efficient. The only meaningful savings on those files come from image recompression — downsampling embedded photos and re-encoding them as smaller JPEGs. Browser-based tools generally don’t do image recompression; reach for Ghostscript locally or a cloud tool you trust if image quality loss is acceptable.

    Does compressing a PDF reduce its quality?

    Structural compression — what our browser tool does — is fully lossless. Text remains pixel-identical, searchable, and selectable. Image recompression (the kind heavyweight tools do) is lossy by design and produces visible artefacts at aggressive settings, especially on photos and scans. Match the compression type to your quality requirements: structural for office docs, image recompression with quality 80+ for photo-heavy files.

    Can I compress a password-protected PDF?

    Not directly — most browser PDF libraries can’t read encrypted PDFs without the password. Unlock the PDF first (using a tool like qpdf with the password, or Adobe Acrobat), compress the unlocked copy, then re-apply password protection if needed. Never share an unlocked copy of a sensitive PDF.

    Will my compressed PDF still be searchable and selectable?

    Yes for structural compression — text remains exactly as it was. For aggressive image recompression on scanned PDFs, the OCR text layer underneath the visual layer might desync slightly if the scanner used JPEG2000-encoded images that get re-encoded. Test searchability after compression, especially before sending to a counterparty who will need to copy text from the file.

    Is there a file size limit on the browser PDF compressor?

    100 MB practical maximum. The actual limit is your browser’s memory — pdf-lib needs roughly 3-4× the file size in RAM during processing, so a 100 MB PDF needs ~350 MB free. Files under 25 MB process in 1-3 seconds; 50-100 MB takes 10-15 seconds. For files larger than 100 MB, use a desktop tool like qpdf or Ghostscript locally.

    How do I make a PDF under 10 MB for email?

    If structural compression doesn’t get you there, run Ghostscript locally with the /ebook preset (downsamples images to 150 DPI, JPEG quality 75) — typically yields 60-85% reduction on image-heavy PDFs. If still over 10 MB, split the PDF in half using our PDF splitter and send as two separate emails, or use a file-share link (Google Drive, Dropbox) instead of attaching.

    Related tools and guides