Compress PDF

Why I built this

In April 2026 I needed to email a signed contract PDF to a landlord in Seoul. The file was 14 MB — Gmail accepts attachments up to 25 MB, but the landlord's corporate email server (Naver Works) had a 10 MB cap, and the message kept bouncing. The first three "compress PDF" sites I tried wanted me to upload the contract — a document with my name, 주민등록번호, and signature — to a third-party server somewhere in Europe so they could call a server-side compression command on it.

One of those sites watermarked the output. Another demanded I "wait 60 minutes between free compressions or upgrade to Pro." A third returned a result barely 200 KB smaller than the input — the compression had failed, but it still asked for my email to send "the result." That is when I closed all three tabs and built this.

Three rules: (1) compression runs in your browser, period — no upload; (2) before/after sizes are shown so you can judge results honestly; (3) no signup, no watermark, no email harvesting. The underlying engine is pdf-lib, the same open-source library that powers our merge, split, and unlock tools. For Korean users dealing with 계약서, 견적서, or 세금계산서 — documents that should never sit in a third-party log — this matters.

How it works under the hood

When you drop a PDF, the file is read into a JavaScript ArrayBuffer with FileReader — a browser API that operates entirely in memory and never touches the network. pdf-lib then parses the PDF into its internal object graph: a tree of pages, fonts, image XObjects, content streams, and cross-references. Compression in our pipeline means three things: packing similar objects into "object streams" (a PDF feature that uses zlib to compress groups of small objects together), dropping unused or orphaned indirect objects, and removing redundant metadata like duplicate font subsets.

What we deliberately do not do is re-encode image data. The JPEGs and PNGs embedded in your PDF are passed through byte-for-byte at their original quality and DPI. This is why our compression is "safe" — you cannot get a blurry output from us — but also why our savings are modest on scan-heavy PDFs. Real image compression requires Ghostscript-class tools running outside the browser; bringing that into WebAssembly would add 30+ MB to the page load, defeating the point.

The bottleneck is RAM. Peak memory during compression is roughly 2-3x the input file size because pdf-lib must hold the original parsed structure, the new compressed structure, and intermediate object streams simultaneously. A 100 MB PDF needs ~300 MB of headroom, which fits comfortably inside a desktop browser tab but might wobble on older mobile devices.

Verify yourself: open DevTools → Network tab, click Clear, then click Compress. The list stays empty of any outgoing fetch carrying your PDF — proof that nothing is being uploaded. The only activity is the initial page load (HTML, JS, CSS) which was already cached on the second visit.

Real use cases

• Emailing contracts to corporate addresses: Naver Works, Daum Mail, and many enterprise Outlook setups cap inbound attachments at 10 MB. A 14 MB contract becomes 9 MB after our compression and slides through.
• Government portal submissions: 홈택스, 정부24, and US IRS upload forms all have size limits (usually 5-10 MB per file). Shrinking a tax PDF below the cap lets you submit without splitting.
• University application bundles: Common App and Korean university portals (인서울 종합전형) accept a single PDF up to a fixed size. Resumes plus transcripts plus essays often exceed it before compression.
• Cloud storage tier limits: Free Dropbox and Google Drive accounts hit their quota quickly with uncompressed scans. A 20% reduction across thousands of PDFs is real disk space saved.
• Slow mobile uploads (지하철, 5G dead zones): A smaller PDF means a faster upload when your connection is weak. Compressing before uploading saves real time on flaky links.

vs other PDF tools

How OhMyPDF Compress compares to popular hosted compression services as of May 2026:

Where competitors win: iLovePDF and Adobe Online run Ghostscript or proprietary image-re-encoding pipelines server-side. For a 50 MB scanned PDF, they can shrink it to 5-10 MB by downsampling 600 DPI scans to 150 DPI — savings we cannot match in-browser without sacrificing visual quality. That is a legit win for them on heavily-scanned documents where size matters more than fidelity. For everyday office documents, our results are comparable and our privacy guarantee is materially stronger.

What this can't do

• Downsample images. A 600 DPI scan stays 600 DPI in the output. We cannot re-encode raster image data in the browser without adding 30+ MB of WebAssembly dependencies.
• Convert RGB to grayscale. Color conversion is a re-encoding operation we deliberately skip to preserve visual fidelity.
• Remove embedded fonts. Some compressors strip non-essential fonts to save space — we keep all embedded fonts to ensure the PDF renders identically on every device.
• Re-encode JPEGs at lower quality. Aggressive JPEG re-encoding is the single biggest size-saver for scan-heavy PDFs, and the single most damaging to visual quality. We do not offer it.
• Handle files over 100 MB. Browser tab memory limits make larger files unreliable; a Chrome tab is typically capped at ~2 GB of heap.

If you need aggressive image-based compression, use Adobe Acrobat Pro (desktop) or Ghostscript via command line: gs -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook is the classic incantation.

Tips for best results

Run compression before merging, not after. Compressing a 50-page merged output sometimes returns minimal savings because pdf-lib already deduplicated shared resources during the merge. Run the compressor on each source PDF first, then merge.

Skip the compressor if your PDF was just exported from Word or Google Docs. Modern office exports are already well-optimized. The compressor will succeed but the "savings" will be 1-2% at best — not worth the round-trip.

For scan-heavy PDFs (over 5 MB per page), use a desktop tool. If your PDF is dominated by photo-quality scans, we cannot help much. The savings live in image data, which is exactly what we do not touch.

Verify the output by opening it. A compressed PDF should look identical to the original. Scroll all the way through to confirm — pdf-lib is mature, but rare edge cases (PDF/A documents, files with unusual encryption flags) can produce subtly different output.

FAQ

Why did my file get bigger after compression? Object stream packing can occasionally produce a slightly larger file when the source PDF used a more compact stream layout that pdf-lib does not replicate exactly. This is unusual — it happens roughly one time in twenty, mostly with PDFs generated by Adobe Acrobat Pro using its tightest "PDF/A" output settings. If you see a size increase, the easiest fix is to keep the original. There is nothing to be gained by compressing an already optimally-compressed PDF.

Will form fields and digital signatures survive? Form fields (text boxes, checkboxes, dropdowns) stay intact and remain editable. Digital signatures will be invalidated because saving the PDF changes the underlying byte content, which breaks the cryptographic hash that the signature was computed over. This is by design — any signed PDF tampering should void the signature. If signatures matter, do not compress: keep the signed version as-is, or compress only before signing.

Is the visual quality affected? No. Browser-side compression does not touch image data — pictures inside the PDF render at the same DPI and quality as the source. We only repack the PDF object structure, drop unused indirect objects, and unify duplicate resources. If you need aggressive image downsampling for big savings (the kind that Adobe Acrobat Pro offers), that requires raster image re-encoding which we deliberately do not run in-browser. Visual fidelity is non-negotiable here.

How much savings should I expect? For PDFs already optimized at export (most modern exports from Microsoft Word, Google Docs, Pages), expect 0-10% reduction — the source is already well-packed. For older PDFs, scanned documents with redundant metadata, or files exported from desktop publishing tools without web optimization, savings can hit 20-40%. The before/after numbers display after each compression so you can see the real impact rather than trusting a marketing claim.

Does this support batch compression? Not currently — one file at a time. Batch processing in the browser is technically possible but memory-intensive (each PDF holds several hundred MB of parsed objects in RAM at peak). For batches of 10+ files, a desktop tool like Adobe Acrobat Pro or Ghostscript via command line is more efficient. If batch ships in a future update we will note it in the changelog.

Why is browser compression weaker than Adobe Acrobat? Adobe Acrobat Pro uses Ghostscript-class image re-encoding: it can downsample 600 DPI scans to 150 DPI, convert RGB to grayscale, and re-encode JPEGs at lower quality. Those are the moves that produce 10x size reductions on scan-heavy PDFs. We cannot run that in a browser because the WebAssembly builds of Ghostscript are 30+ MB and would balloon page load time. The trade-off is honest: we are faster and private; Acrobat is stronger but uploads to Adobe servers.

Does my PDF leave my browser during compression? No. The PDF is read into a JavaScript ArrayBuffer using FileReader (a purely in-memory browser API), pdf-lib rewrites the object structure locally, and the compressed result is offered as a download Blob. Open DevTools → Network tab, clear the log, then click Compress — you will see exactly zero outgoing fetch requests carrying your file. Most hosted competitors cannot match this because their compression algorithms run on their servers.

Why is the maximum file size 100 MB? Browser memory is the hard constraint. Decompressing a PDF for re-packing roughly doubles its peak RAM footprint, and most browsers cap each tab at 2 GB of heap. A 100 MB ceiling leaves comfortable headroom for the working memory needed to parse, modify, and re-serialize. Files over 100 MB are usually scan-heavy PDFs that benefit more from image-based re-encoding (a desktop tool) than from object stream optimization (what we do).

My result looks identical in size — what went wrong? Nothing went wrong. Many PDFs are already well-compressed at export. If you produced the PDF from a modern source (recent Microsoft Office, Google Workspace, web "Print to PDF"), the export is already optimized and there is no slack for us to recover. The compression ran successfully; there simply was nothing left to save. Try the same PDF in iLovePDF or SmallPDF — if their result is dramatically smaller, you are seeing image re-encoding, not structure optimization.

Why use this instead of iLovePDF compression? Privacy is the headline difference: your PDF never reaches a server, which matters for tax returns, contracts, and signed documents. iLovePDF and SmallPDF run server-side Ghostscript and will achieve bigger reductions on scan-heavy PDFs, so for pure size-reduction on a non-sensitive scanned report they may win. For office documents and well-exported PDFs (the majority of everyday use), our reduction is comparable and the privacy guarantee is materially stronger.