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

Diagram showing an 8.4 MB PDF being structurally compressed to 5.1 MB — a 39% size reduction — by the simpletool.io free PDF compressor running entirely in the browser
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