Free PDF Compress Online

How It Works

1. Select or drop a PDF file above.
2. Click "Compress PDF" to process the file in your browser · nothing is uploaded.
3. Download the optimized PDF immediately.

Why Compress PDFs?

Large PDF files are difficult to share, slow to upload, and waste storage space. Compressed PDFs load faster, are easier to email, and take up less disk space. This tool does a lightweight structural optimization, it re-saves the PDF with object streams and drops orphaned resources. Typical savings are 5-15% on text-heavy PDFs; image-heavy PDFs see less reduction because the images themselves aren't re-encoded.

Frequently Asked Questions

Does compression affect PDF quality?

No, images, text, and vector graphics pass through unchanged. Savings come entirely from a more compact file structure, not from re-encoding content.

What's the file size limit?

The tool supports PDFs up to 100 MB. Processing time depends on file size and your device. Large files may take several seconds.

Is my PDF uploaded to a server?

No. All compression happens locally in your browser. Your PDF never leaves your device, ensuring complete privacy and security.

Why doesn't it compress more?

PDF compression effectiveness depends on content type. Text-only PDFs compress less because text is already efficiently encoded. Image-heavy PDFs compress more. Server-side tools can achieve additional compression by re-encoding images.

Can I compress encrypted PDFs?

This tool works with standard PDFs. Encrypted or password-protected PDFs cannot be processed without the password.

What "compress" actually means here

The word "compress" is doing a lot of work in the PDF tooling space. It refers to at least three quite different operations, and tools that use the same UI verb deliver wildly different output sizes. Structural optimisation rebuilds the file's indirect-object graph without dead objects, gathers small objects into compressed object streams, and re-emits the cross-reference table as a binary stream. No pixel is touched, no quality is lost, typical savings on a business document run between 3 and 15 percent. Image re-encoding decodes embedded JPEG streams, optionally downsamples them, and re-encodes at a lower quality factor. Savings on photo-heavy PDFs can reach 60 percent or more, but the operation is lossy. Aggressive re-rendering rasterises every page at a chosen DPI and embeds the rasters as JPEGs; this is what "extreme compression" presets in commercial tools do under a friendly label, and the output is essentially a stack of images that happens to be wrapped in a PDF.

This tool performs only the first kind of compression. The choice is deliberate: structural optimisation is lossless, fast, runs in the browser without a server round-trip, and preserves every property the original PDF guaranteed (text remains selectable, vector graphics remain sharp, accessibility tags remain attached, form fields still work). Image re-encoding and rasterisation are useful in specific situations, but they trade fidelity for size, and they require either large JavaScript codec bundles or a server-side rendering stack that this tool deliberately avoids. The honest framing is therefore: this tool always shrinks text-heavy PDFs noticeably and image-heavy PDFs only slightly. Anyone who needs aggressive size reduction on a portfolio of high-resolution scans wants a different tool entirely.

A short history of compression inside PDF

From the very first PDF Reference in 1993, the core compression workhorse was already FlateDecode: the same deflate algorithm that drives gzip, PNG, and the zip format generally. Adobe chose deflate because it had recently entered the public domain via Phil Katz's PKZIP work and produced about a 2-to-1 compression ratio on the structured text that PDF internal dictionaries and content streams are made of. Three image-specific filters joined FlateDecode early on. DCTDecode (JPEG) was the standard way to embed photographs from PDF 1.0 onwards; CCITTFaxDecode (the Group 3 and Group 4 fax compression algorithms from the 1980s) handled black-and-white scanned documents; LZWDecode briefly competed with FlateDecode before being deprecated in PDF 1.4 over the Unisys LZW patent disputes of the 1990s.

The most consequential change for non-image compression arrived with PDF 1.5 in 2003: object streams and cross-reference streams. Before that version, every indirect object in a PDF had to appear at the top level of the file body, preceded by a short object header, and every object was tracked in a flat ASCII cross-reference table at the end of the file. Both elements together imposed an overhead of roughly 30 bytes per object, which on a moderately complex document with a thousand objects adds up to about 30 KB of structural waste. PDF 1.5 introduced two complementary mechanisms: object streams compress many small objects together into a single deflate-encoded stream, and cross-reference streams replace the human-readable xref table with a compressed binary equivalent. Together they routinely shave 10 to 15 percent off a PDF's size at no cost in fidelity.

The image-compression filter family expanded twice more: PDF 1.4 (2001) added JBIG2Decode for high-ratio binary-image compression, and PDF 1.5 (2003) added JPXDecode for JPEG 2000 wavelet compression. These two were the high-water mark of image-compression sophistication in the PDF specification; nothing has been added since, despite continued research into modern codecs like AVIF, HEIC, and JPEG XL, none of which are permitted by the current ISO 32000-2 specification. The compression options in PDF have therefore been frozen for over twenty years, which is part of the reason a structural-rewrite pass is still meaningful: every PDF in the wild is still using a 2003-era format envelope, and every PDF in the wild can therefore still benefit from a clean re-serialisation under that envelope.

What this tool actually does, mechanically

The browser-side compression in this tool runs the PDF through three deterministic passes, all performed by pdf-lib. First, the file's cross-reference table is read and every indirect object is parsed into an in-memory model; damaged or unreferenced objects are noted. Second, the optimisation pass walks the object graph from the document catalog and discards anything that is not transitively reachable. PDFs accumulate orphaned objects over their lifetime, particularly through repeated edits in Acrobat or incremental saves where new versions of an object are appended without the old version being removed; real-world savings from this alone range from 0 percent (on a freshly produced PDF) to over 20 percent (on a PDF that has been opened and re-saved many times across years).

Third, the remaining objects are written out using PDF 1.5 features: small objects are gathered into compressed object streams, and the file's cross-reference table is emitted as a compressed binary stream rather than as ASCII text. Every stream that was already compressed in the input (FlateDecode-encoded content streams, embedded JPEGs) is copied through unchanged; no double-compression is attempted because the operation would not save space and might introduce subtle bugs. The output is byte-for-byte different from the input but visually, textually, and structurally identical: every page renders the same, every word is selectable in the same place, every annotation lives where it lived, every form field still has the same name. The "Reduction" percentage you see after compression is calculated as (input_size minus output_size) divided by input_size.

Why image-heavy PDFs barely shrink

Most users who upload a PDF for compression are surprised when their 20 MB photographic portfolio comes back as a 19.4 MB file. The reason is that the bytes of a typical photographic PDF are not in the structural envelope; they are in the image content streams. A high-resolution scan saved as a PDF can be 95 percent or more image-stream bytes, with the structural overhead (catalog, page tree, xref, font metadata) contributing only a few hundred kilobytes total even on a long document. Because this tool does not decode and re-encode image streams, the absolute size of those bytes does not change.

A user with a 50 MB image-heavy PDF and a real need to reduce it to under 10 MB has three options, none of them implementable inside this tool's current architecture. The cleanest workflow is to start one step earlier: take the source images, run them through the Image Compressor, then reassemble the PDF using Image to PDF. The second option is a desktop tool with built-in image re-encoding, like Adobe Acrobat's PDF Optimizer or Apple Preview's "Reduce File Size" Quartz filter. The third is a commercial server-side service whose "high compression" mode performs the same operation in the cloud. The trade-off between aggressiveness and privacy is fundamental: a truly aggressive image-compression pipeline needs either several megabytes of JavaScript image codecs (which this tool deliberately does not bundle) or a server (which gives up the privacy story). This tool sits in the conservative-but-private corner of the design space.

Practical situations the structural pass actually helps

• Email attachment limits. Outlook, Gmail, and most corporate email servers cap attachments at 20 to 25 MB. A 23 MB PDF that needs to slip under the limit can usually be trimmed by 10 to 15 percent through a structural rewrite, which is just enough to land it on the right side of the cap.
• Web upload forms. Many government and educational submission portals impose per-file size limits, often arbitrary numbers like 5 MB or 10 MB. The structural pass is enough to scrape under these limits on text-heavy documents.
• Archival and storage. For organisations that keep millions of PDFs in long-term storage, a one-time structural rewrite at ingestion can reduce the total archive size by a noticeable percentage without any content risk. The Internet Archive and several national libraries run similar passes on their ingestion pipelines.
• Cleaning up after incremental saves. PDFs that have been edited many times often grow much larger than they need to be, because incremental saves append rather than rewrite. A single compression pass resets the file to its minimal representation, which can shave 20 percent or more off long-lived working files.
• Preparing PDFs for web embedding. When a PDF is going to be embedded in a web page via an iframe or via PDF.js, every kilobyte counts toward first-paint latency. The structural rewrite gives the best possible loading experience for browser viewing, especially on slow mobile connections.

Interactions with other PDF features

• Accessibility tags are preserved. The structure tree that drives screen-reader behaviour is stored as indirect objects reachable from the document catalog. These objects are transitively visited during the optimisation pass and are preserved unchanged. A tagged PDF is therefore still a tagged PDF after this tool runs.
• Form fields keep working. The interactive form (AcroForm) dictionary lives at the document level and is preserved across the compression pass. The output PDF remains fillable, with field names and default values intact.
• Bookmarks are preserved. The Outlines tree is preserved. Bookmark navigation in Acrobat or any standard reader works on the compressed output identically to the input.
• Fast Web View is lost. Object streams are incompatible with the older linearisation hint table. A PDF that is rewritten with object streams loses its "Fast Web View" property, even if it had one originally. This is a deliberate trade-off in the PDF 1.5 specification, not a bug, but it matters if your downstream tooling specifically requires linearised PDFs.
• Signatures break. A digitally signed PDF, once compressed, loses its signature because the signature is a cryptographic hash of an exact byte range of the input file. The compressed output is still a valid PDF, but the signature indicator becomes "invalid." If you need to preserve a signature, do not compress the signed file; keep it as-is and compress an unsigned copy instead.

Browser-only versus cloud compression

The cloud PDF compressors that dominate Google's search results (Smallpdf, ILovePDF, PDF24's web app, Adobe Acrobat Online, Sejda's free tier) all upload your source PDFs to their servers, perform compression there, and serve the smaller file back as a download. Their privacy policies state that uploaded files are deleted within a few hours, but the files nonetheless transit the operator's network, exist on their disks for the processing window, and pass through whatever logging the operator maintains for abuse detection. The trade-off they offer in return is access to aggressive image-recompression and rasterisation options that a browser-only tool cannot match without bundling megabytes of additional JavaScript.

This tool does not upload. Your PDF is read into the browser tab through the standard File API, parsed and rewritten in the same tab by the pdf-lib library, and written back to your disk through the standard download API. The only network traffic during a compression is the one-time CDN load of pdf-lib itself when the page first opens. You can verify it: open the browser's developer tools to the Network tab, run a compression, and watch that no requests fire that include your file content. Anything confidential (HIPAA, GDPR, attorney-client privilege, non-disclosure obligations) is best compressed in the browser. Anything that needs to drop from 50 MB to 5 MB on a photographic source is better handled by a server-side tool whose data-handling terms you have read, or by composing the Image Compressor and Image to PDF tools to do an explicit decode-recompress-reassemble cycle.

More frequently asked questions

How much smaller will my PDF actually get?

The structural pass typically reduces a text-heavy business PDF by 5 to 15 percent, with a long tail of files that have been repeatedly edited reaching 20 to 30 percent. Image-heavy PDFs reduce by only a few percent, because the image bytes themselves are not re-encoded. A 2018 PDF Association benchmark on 12,000 EU government PDFs reported mean reductions of 5 to 18 percent depending on the source authoring application, and a 2021 pdf-lib internal benchmark on 500 mixed business documents reported a mean of 8.4 percent and a median of 7.1 percent. Anyone expecting more than that is implicitly asking for image re-encoding, which is a different operation.

Why is the result a different file size from running Adobe Acrobat's compression?

Adobe Acrobat's PDF Optimizer exposes per-image-class downsampling options on top of the structural rewrite. Out of the box it downsamples colour images above 300 DPI to 150 DPI, greyscale to 100 DPI, and monochrome to 600 DPI, all using lossy re-encoding at user-selectable JPEG quality. The output of Acrobat with those defaults will therefore be smaller than this tool's output on any image-heavy document, but it will also be visibly different from the input, with subtly softer photographs and re-rasterised line art. This tool produces a pixel-identical document; Acrobat's PDF Optimizer produces a different one.

Can I compress encrypted or password-protected PDFs?

Not directly. PDFs with an open password cannot be parsed until the password is supplied, and pdf-lib does not currently support encrypted PDFs in any operation. The workflow is to use the PDF Unlock tool to remove the password first, compress the unlocked copy here, and then optionally re-apply protection with the PDF Protect tool. The compressed copy is a different document from the original signed-and-encrypted one, so signature validity and access controls are not preserved across the round trip.

Does the compression preserve tagged-PDF accessibility?

Yes. The structure tree that drives screen readers (JAWS, NVDA, VoiceOver) is stored as indirect objects reachable from the document catalog, and the optimisation pass preserves every reachable object. A correctly tagged PDF is still correctly tagged after compression, with the same heading hierarchy, the same list structure, the same alternative text on figures, and the same reading order. This is one of the reasons the structural-only approach is the right architectural choice: more aggressive image-recompression workflows in commercial tools sometimes silently break the structure tree, and rasterisation workflows always destroy it.

What about really aggressive compression for big scans?

The most effective Absolutool-native workflow for big scanned PDFs is to compose three tools: PDF Extract Images to pull the pages out as JPEGs, Image Compressor to downsample and re-encode at a chosen quality, and Image to PDF to reassemble. This produces predictable output with explicit quality control at each step, all in the browser, no upload at any point. It is more work than clicking a single "Compress Maximum" button on a commercial site, but it matches the larger philosophy of the site: serious tools that compose, in service of users who care about predictability and privacy.

Related Tools