Category: PDFs

  • Split PDF Online: Browser-Only, 100% Private [2026]

    Split PDF Online: Browser-Only, 100% Private [2026]

    TL;DR: Splitting a PDF means producing one or more smaller PDFs from a larger one — by page range (pages 1–10), every page (one file per page), every N pages, or by extracting specific page numbers. Our free PDF splitter runs pdf-lib entirely in your browser. Files never upload — important when splitting contracts, payslips, medical records, or anything you wouldn’t paste into a free upload-to-server tool.

    Splitting a PDF is the kind of task that feels small until you need to do it with a sensitive file. The default workflow — Google “split pdf” → upload to ilovepdf or smallpdf — sends your contract, salary sheet, or hospital record through a stranger’s server, where it sits in their cache for hours. For the same task, browser-only tools using pdf-lib (the JavaScript library that powers most modern PDF utilities) do the work locally with no data leaving your machine.

    Our PDF splitter handles the four common modes — page range, every page, every N pages, extract specific pages — with drag-and-drop input and one-click ZIP download for multi-file outputs. This guide explains exactly what each mode does, the technical limits, the privacy difference between browser and server splitters, and the gotchas with bookmarks and form fields.

    The 4 split modes — and which one you actually want

    Mode Output Best for
    Page range 1 file containing pages X–Y Extracting a chapter or section
    Per page N files, one page each Multi-page invoices, scanned receipts
    Every N pages ⌈N/k⌉ files of k pages each Splitting a long report into chapters
    Extract pages 1 file containing only the listed pages Pulling specific pages out of a deck
    Multi-range Multiple files, one per range Splitting a combined PDF into sections

    Privacy: browser-only vs server-based splitters

    Most “free PDF splitter” sites upload your file to their server, run the split there, and let you download the output. That means: your file sits in their cache for some retention period (often 24 hours, sometimes longer); their backups potentially preserve it; their privacy policy controls what happens to it. For a marketing brochure that’s fine. For a contract, payslip, medical record, signed legal document, or anything you’d email with care — it’s not.

    Our PDF splitter uses pdf-lib, a JavaScript library that runs entirely in the browser. When you drop a file in, the bytes never leave your tab. You can verify this in your browser’s Network tab — the file selection triggers zero outbound requests. The split files appear in your browser’s download folder via a local blob URL, not a server response.

    How to split a PDF in your browser

    1. Open the PDF splitter
    2. Drop your PDF into the upload zone, or click to pick a file
    3. Pick the split mode: Range, Per page, Every N pages, Extract, or Multi-range
    4. Type the page numbers (1-5, 8, 12-20 for multi-range)
    5. Click Split — output files appear immediately
    6. Click Download all (ZIP) for multi-file output, or download each file individually

    Technical limits and what to expect

    pdf-lib runs in WebAssembly and is fast for moderate-size PDFs:

    • Up to ~100 pages, mixed text and images: instant (under 1 second)
    • 100–500 pages with embedded fonts: 2–10 seconds
    • 500–1000 pages, scanned image-heavy: 10–60 seconds, may briefly stall the page
    • 1000+ pages or files over 200 MB: at the edge of browser memory; consider splitting in batches
    • Encrypted (password-protected) PDFs: require the password before splitting; pdf-lib supports both user and owner password

    Memory is the real limit. Mobile browsers are more restrictive than desktop — a 200 MB PDF that splits cleanly on a laptop may crash an iPhone Safari tab. For very large files, use the desktop browser or split in two stages.

    Common gotchas

    • Bookmarks and outlines. When you split a PDF, bookmarks pointing to extracted pages are preserved; bookmarks pointing to pages outside the new file are dropped. This is the correct behaviour but surprises people who expect the entire outline to follow.
    • Form fields. Interactive form fields (signature blocks, checkboxes, text inputs) on extracted pages keep their values. Fields on dropped pages are removed. Form-level metadata (default values, validation rules) is preserved at the document level.
    • Annotations and highlights. Comments, highlights, and stamps on extracted pages move with them. Annotations referencing dropped pages may show a broken link icon.
    • Linked TOCs break. A table of contents with hyperlinks to specific pages becomes partially broken when you split — half the links point to non-existent pages. Either remove the TOC or split before generating the TOC.
    • Output file names. Default naming is filename-part-N.pdf. Customise with the “Filename pattern” input — {name}-{from}-{to}.pdf tokens are supported.
    • Compression isn’t preserved by default. pdf-lib re-streams content; deeply-compressed input PDFs may grow ~5% in the output. To keep size down, run the output through a PDF compressor after splitting.

    When NOT to use this tool

    If you need OCR, deskewing, or text extraction, a PDF splitter won’t help — those are different workflows. For batch automation in a build pipeline, install pdf-lib locally (npm i pdf-lib) and write a Node script — same engine, more control. For PDFs with PDF/A archive compliance requirements, use Adobe Acrobat or PDF Studio Pro to preserve the compliance metadata; pdf-lib outputs standard PDFs that may not validate as PDF/A. For password-protected files where you don’t have the password, no tool will help — that’s the security working as intended.

    Frequently asked questions

    Is my PDF uploaded?

    No. The splitter uses pdf-lib running in your browser. The file is loaded into a blob URL in your tab, processed locally, and the output is generated from the same in-memory data. You can verify in DevTools’ Network tab: dropping a file produces zero outbound requests.

    What’s the largest PDF I can split?

    Effectively your browser’s available memory. On desktop, files up to 200 MB and 1,000+ pages work. On mobile, the practical limit is around 50 MB. If a split fails, refresh the tab to free memory and try again with a smaller batch.

    Can I split a password-protected PDF?

    Yes — paste the user password in the prompt that appears when you upload. The splitter handles both user passwords (open access) and owner passwords (edit access). Password-protected files where you don’t know the password cannot be split — that’s the encryption working correctly.

    Does the split preserve form fields and signatures?

    Form fields and electronic signatures on extracted pages are preserved. Fields and signatures on dropped pages are removed (they wouldn’t be valid in the smaller file anyway). Visible certificate-based signatures from Adobe or DocuSign keep their visual representation; cryptographic validity depends on whether the signed scope changed.

    How do I split a PDF into individual pages?

    Pick the “Per page” mode. A 30-page input becomes 30 single-page output files in a ZIP. Useful for archiving multi-page invoices into one file per invoice, or pulling each scanned receipt out of a batch capture.

    Will splitting reduce the file size of each part?

    Roughly proportional to page count — splitting a 30 MB / 30-page PDF into 3 files yields three ~10 MB files. Embedded fonts and images are included only in the parts that reference them, so files with shared graphics may be slightly smaller than 1/N. To shrink further, run each output through a PDF compressor.

    Related tools and guides

     

  • Make PDF Look Scanned: Browser-Only Converter [2026]

    Make PDF Look Scanned: Browser-Only Converter [2026]

    TL;DR: A “scanned PDF converter” makes a clean digital PDF look like it came out of a real scanner — adds skew (slight rotation), paper grain, faded ink, edge shadows, and downsamples to 96–150 DPI. Used for forms that demand “scanned” submissions, courtesy submissions where a printout-and-rescan would be the official process, and for visual consistency in workflows that mix scanned and digital documents. Our free scanned PDF converter runs entirely in your browser using pdf-lib + canvas filters.

    The “please submit as a scanned PDF” requirement is one of the small absurdities of digital paperwork. A perfectly valid digital signature is rejected by an HR system that still parses scanned forms only. A government portal expects an “ink-on-paper” feel even though the form was filled in Word. Some e-discovery systems flag clean PDFs as suspicious because they assume real submissions go through a copier. The fix: take your clean digital PDF and run it through filters that mimic the artefacts of a real scan — grain, skew, faded edges, slightly off-white paper.

    Our scanned PDF converter applies five effects in combination: skew (random ±2° rotation per page), grain (paper texture noise), ink fade (slight contrast reduction), edge shadow (vignetting from the scanner glass), and resolution downsample (rasterise to 150 DPI). The result passes most “looks scanned” detectors without any of the security concerns of uploading sensitive forms to an unknown server. This guide covers each effect, when to use this for legitimate workflows, and the legal grey areas to avoid.

    The 5 effects and what each fixes

    Effect Tells it fixes Default value
    Skew Perfectly aligned page edges ±1.5° rotation per page
    Paper grain Pixel-perfect text and uniform background 8% noise, low contrast
    Ink fade Pure black text, 100% saturation Reduce contrast 12%, RGB shift to #1a1610
    Edge shadow Razor-sharp page boundaries 12px gradient at edges, 30% opacity
    Resolution Vector-perfect text rendering Rasterise to 150 DPI
    Paper tint Pure white background #fdfaf2 (off-white)
    JPG compression Sharp PNG-grade quality JPG quality 80, slight blocking

    Three intensity presets

    Most users don’t need to tune individual sliders. The presets cover 95% of cases:

    • Light: subtle grain and skew, retains text crispness. For legitimate forms where the scanned look is a courtesy.
    • Medium (default): noticeable grain, ink fade, edge shadow. The “honest scan” preset.
    • Heavy: aggressive aging — strong grain, brown paper tint, more skew. For documents you want to look old or photocopied many times.

    Pick a preset, preview the first page, adjust if needed.

    How to make a PDF look scanned

    1. Open the scanned PDF converter
    2. Drop your PDF in
    3. Pick a preset: Light, Medium, or Heavy
    4. Adjust skew amount, grain intensity, paper tint, and resolution if needed
    5. Click Convert. Each page is rasterised, processed, and re-embedded
    6. Download the converted PDF — typically 2–4× the original file size due to raster pages

    Legitimate uses (and the line you shouldn’t cross)

    Legitimate:

    • Forms that demand a “scanned” submission for visual consistency (HR forms, some legal templates, some government portals)
    • Submitting a digital fill of a form designed to be printed-and-scanned
    • Visual consistency in mixed scanned/digital archives
    • Mock-ups for UI design (e.g., showing what a scanned doc looks like in a doc-management UI)
    • Educational examples of OCR pre-processing

    Don’t:

    • Forge documents — making a fake invoice “look scanned” to deceive someone is fraud, regardless of whether you used Photoshop or this tool
    • Pass off a generated document as having gone through a paper original — for any document that requires a wet-ink signature, use one
    • Strip metadata to hide the original source from a fraud investigation
    • Manipulate evidence — adding “scanned” artifacts to a document submitted in legal proceedings is evidence tampering

    The tool is for honest workflows. If your use case requires the recipient to believe the file went through a paper-and-scanner pipeline that it didn’t, you’re in fraud territory.

    Common gotchas

    • File size grows. Rasterising vector pages to images (even at 150 DPI) typically 2–4× the original file size. A 1 MB digital PDF becomes 2–4 MB scanned-look output. Run through a PDF compressor after if size matters.
    • Text becomes uncopyable. The output is image-based — selecting text returns nothing. Most workflows treat that as a feature (real scans are also image-based until OCR). If you need selectable text, don’t run this conversion.
    • Search engines and accessibility tools can’t read it. A converted PDF has no machine-readable text — which is fine for forms but bad for archival. Keep the digital original.
    • Skew direction. Use random ±skew per page, not constant ±skew. A constant tilt looks like a misaligned scanner, not a stack of slightly-misfed pages.
    • Paper colour. Pure white (#FFFFFF) is the giveaway — real scans land on slightly off-white because of paper colour, ambient light, or scanner sensor calibration. Even at “Light” preset we tint to #fdfaf2.
    • Line art. CAD drawings and line-art-heavy documents can look damaged after grain + downsample. Test before processing technical drawings.

    When NOT to use this tool

    For documents that require legal authenticity (contracts, medical records, court filings), skip the conversion — submit the original PDF if possible, or scan a printed copy of the wet-signed version. For OCR or text extraction, the conversion makes things worse, not better — keep the digital original. For batch processing (100s of files at scanned-look output), install pdf-lib + sharp locally and script the conversion. For sensitive material where even browser processing is too risky, use offline software like ImageMagick on an air-gapped machine.

    Frequently asked questions

    Why would I want to make a PDF look scanned?

    Forms that demand “scanned” submissions for visual consistency, government portals that flag clean PDFs, HR systems that only accept scan-style files, and visual consistency across archives that mix scanned and digital documents. Always for honest workflows — fabricating documents to deceive someone is fraud regardless of the tool.

    Will the converted PDF still have selectable text?

    No. The conversion rasterises each page, so the output is image-based. Selecting text returns nothing. Most workflows that demand “scanned” PDFs expect this — real scans are also image-based until OCR is applied. If you need selectable text, don’t run this conversion.

    How much does the file size grow?

    Typically 2–4× the original. A 1 MB digital PDF becomes 2–4 MB after raster conversion at 150 DPI. Run the output through a PDF compressor if size matters — a moderate compression brings it back close to the original size while keeping the scanned look.

    Is this legal?

    The tool itself is legal everywhere. The output’s legality depends on use. Submitting a converted file to a workflow that demands “scanned” format for visual consistency is fine. Using it to forge documents (fake invoices, fake official records) is fraud regardless of the tool.

    Is my PDF uploaded?

    No. The converter runs in your browser using pdf-lib + canvas. The file loads into a blob URL and never leaves your tab. You can verify in the Network tab — zero outbound requests after upload.

    Can I undo the conversion?

    No — once rasterised, the original vector text is gone. Always keep your digital original in a separate file. The converted file is a one-way derivative, not a wrapper around the original.

    Related tools and guides

     

  • 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