By PDFKits Team — Published February 19, 2026
TL;DR. A 12 MB PDF on a marketing landing page can be cut to 1.5–2.5 MB without visible quality loss by linearizing the file, downsampling embedded images from 300 dpi to 144 dpi, subsetting fonts to actually-used glyphs, and stripping orphaned objects. Linearization in particular lets the browser begin rendering the first page before the rest of the file has downloaded — critical for slow mobile connections. PDFKits handles all four optimizations in the browser; for batch-optimizing 100+ marketing assets, a desktop tool (Acrobat Pro at $29.99/month) or a CLI (Ghostscript) is faster, but for single files browser processing is identical in output.
A whitepaper hosted on a marketing site that weighs 12 MB takes 8 seconds to download over a 12 Mbps mobile connection — long enough that 30%+ of visitors abandon before the first page renders. The same PDF after optimization weighs 1.8 MB and downloads in 1.2 seconds. The user sees the first page within 400 ms because the file is linearized: page 1 streams before pages 2–40 are even on the wire. Google PageSpeed scores reflect this directly through Largest Contentful Paint (LCP). For PDFs served directly (not behind a viewer), the file itself is the LCP element.
Most PDFs hosted online are unoptimized exports from Word, InDesign, or Photoshop, where the default export embeds full-resolution images, full fonts, and no linearization. Optimizing brings a typical marketing PDF from 8–15 MB to 1–3 MB at no perceptual cost. The four levers that move the needle are image downsampling, font subsetting, linearization, and object cleanup — in that order of impact.
Images make up 70–95% of the weight of a typical PDF. A product brochure with 20 photos at 300 dpi adds about 600 KB per page. Dropping to 144 dpi — sharp on Retina screens, indistinguishable to most viewers — cuts each image to about 140 KB. For a screen-only PDF, 144 dpi is sufficient; 300 dpi is wasted unless the user prints. PDFKits Optimize PDF downsamples to a target dpi while preserving aspect ratio and color profile. For brochures intended for print AND web, host two versions.
A typical PDF that uses Helvetica Neue with all 11 weights embeds about 1.1 MB of font data. Subsetting keeps only the glyphs that actually appear in the document — for an English-only marketing PDF, that's typically 200–400 glyphs out of the 2,500+ in the full font. Most modern PDF exporters (InDesign, Word) already subset by default, but documents created by older tools or by concatenating PDFs from different sources often have full fonts embedded.
A linearized PDF is restructured so the first page's content sits at the start of the file, followed by an index that lets the viewer jump to any other page. The browser can render page 1 after downloading the first ~80 KB rather than waiting for the full file. For a 40-page PDF served on a slow connection, linearization can drop perceived first-render from 6 seconds to 400 ms. The total file size is unchanged.
Documents built up over multiple editing sessions accumulate orphaned objects — old form field definitions, deleted images still in the object table, unreferenced thumbnails. Stripping these and removing creator metadata (which often leaks user names and file paths) reclaims modest space and improves privacy. The savings are smaller than image downsampling but the cleanup is free.
A B2B SaaS product page links to a 14 MB technical whitepaper. The download triggers a 12-second wait on a typical mobile connection. After running Optimize PDF with image downsampling to 150 dpi and linearization, the file is 1.9 MB and downloads in 1.4 seconds. Marketing tracks a measurable lift in completed downloads after the change.
A developer-tools company exports its API reference as a 220-page PDF for offline use. The export is 40 MB. Subsetting fonts (4 weights of Source Sans Pro), downsampling diagrams from 600 to 200 dpi, and linearizing brings it to 6 MB — small enough to host on the docs CDN without bandwidth concerns.
A history professor uploads scanned reading packets to the course LMS. The unoptimized scans average 80 MB per packet. Image-mode compression with downsampling to 200 dpi brings each packet to 8–12 MB, well under the LMS's 25 MB per file limit, while keeping text legibility for students.
An environmental NGO publishes a 60-page illustrated annual report. The InDesign export is 28 MB. After image downsampling, font subsetting, and linearization, the file is 4.2 MB — short enough to email to donors without a Dropbox link and small enough to load quickly on the NGO's site.
A regulatory affairs team hosts SEC filings, public comments, and amicus briefs on the firm's site. Optimization is required because filings often run 80–200 pages with embedded exhibits. Linearization is the dominant win — users need fast access to a single referenced page, not the whole document.
Drag the PDF into Optimize PDF. Choose a target: Lite (visual quality priority, typically 20–40% reduction), Web (balanced for screen reading, typically 50–70% reduction with downsampling to 144 dpi), or Aggressive (smallest size, typically 70–85% reduction with downsampling to 100 dpi and JPEG quality reduction). For most marketing PDFs, Web is the right default. Click Optimize. The tool downsamples embedded images, subsets fonts to glyphs actually used, linearizes the result for progressive download, and rewrites the file with stream compression. Download the optimized file. Total processing time for a typical 30-page PDF: 5–15 seconds.
For a sanity check after optimization, open the file in Acrobat Reader (or any major PDF reader), zoom to 200% on a text-heavy page, and confirm text is still sharp. If text looks fuzzy, you over-compressed — re-run with a less aggressive preset. For image-only PDFs (e.g., scanned reading packets), run OCR PDF first to add a text layer before optimizing, so the resulting file remains searchable.
| Feature | PDFKits | Adobe Acrobat Pro | Ghostscript (CLI) | Smallpdf Pro |
|---|---|---|---|---|
| Cost | Free | $29.99/month | Free (open source) | $108/year |
| Files stay on your device | Yes | Yes (desktop) | Yes | No — cloud |
| Linearization (Fast Web View) | Yes | Yes | Yes | Yes |
| Image downsampling to target dpi | Yes | Yes (granular) | Yes (granular) | Limited presets |
| Font subsetting | Yes | Yes | Yes | Yes |
| Batch processing (100+ files) | Manual (one at a time) | Action Wizard | Scriptable | Cloud queue |
| No installation | Yes | No | No | Yes |
Ghostscript is the fastest option for a batch of 100+ marketing assets if you are comfortable with the command line — a one-line invocation with -dPDFSETTINGS=/screen handles most cases. For single-file optimization or for documents that cannot be uploaded (privileged client material, draft work product), PDFKits produces identical results to the desktop tools without a vendor in the path.
Three measurements matter. First, file size reduction — straightforward, just compare bytes before and after. Aim for 50%+ reduction on image-heavy PDFs; if you got less, image quality preset was probably too conservative. Second, perceived first-render time — open the file in Chrome DevTools Network tab with throttling set to "Slow 4G," and observe Time to First Contentful Paint (look at the page render, not the network completion). A linearized PDF should render page 1 within 500 ms even on slow connections. Third, visual sanity check — zoom to 200% on text-heavy and image-heavy pages and confirm nothing has degraded below the readability threshold.
For automated regression on a marketing site, host the PDF in the site repo and run a CI check that fails the build if the file exceeds a size cap (e.g., 3 MB for whitepapers, 1 MB for one-pagers). This catches accidentally re-uploaded unoptimized files.
Optimization cannot fix a PDF that is fundamentally an image dump of a Word document. If the original is image-only (scanned pages), the floor on file size is the image data — text rendered as glyphs would have been 50× smaller per page. Rebuild from the source document where possible. Optimization also cannot improve a PDF's accessibility, fix tagging for screen readers, or repair a corrupted file. Each of those problems has a dedicated tool (Edit PDF for tagging, Repair PDF for corruption).
Aggressive optimization presets can cross the line into illegibility. The most common failure mode is downsampling line-art diagrams (architectural drawings, circuit schematics) from 600 dpi to 150 dpi — fine for photos, disastrous for line art. If a PDF contains diagrams, optimize at 200 dpi minimum, or use the Lite preset.
No. Text is stored as vector glyphs and remains sharp at any zoom level after optimization. Only embedded images are reduced in resolution — and only if the resolution exceeds the target dpi setting.
Not with PDFKits. The optimization runs entirely in your browser using pdf-lib and PDF.js. The file never crosses the network.
Compression reduces the file size (via image downsampling, font subsetting, stream compression). Linearization rearranges the file so the first page can render before the rest downloads — it does not change the total size, only the streaming behavior.
For a 30–60 page whitepaper with photos, the Web preset (target around 144 dpi, balanced JPEG quality) hits the right balance. Target a final size of 2–4 MB. Below 1 MB usually means visible quality loss on photos; above 5 MB means the file is bigger than needed for screen reading.
No. Hyperlinks, bookmarks, and outline structures are preserved through optimization. They live in the PDF object table independent of the page content streams.
Yes. The video and form objects are preserved but the surrounding images and fonts get optimized. For PDFs that are primarily interactive (e.g., training assessments), the size reduction will be smaller because there are fewer image bytes to reclaim.
Yes, partially. PDF/A requires all fonts fully embedded (no subsetting) and prohibits certain compression schemes. If a document must be both PDF/A-compliant and web-served, accept that the file will be larger — typical PDF/A files are 30–50% larger than the same content optimized for web.
Open the optimized file in Adobe Reader → File → Properties → Description tab → "Fast Web View" should read "Yes". If it reads "No", the linearization did not apply (likely the source file had structural issues).
PDFKits processes one file at a time. For batches above a few dozen files, a Ghostscript command-line invocation in a shell script is faster. The same image downsampling and linearization logic applies; only the batching mechanism differs.
No. Encryption and password protection are preserved through optimization. The optimized file retains the same access controls as the source.
Optimize PDF — Web optimization with image downsampling, font subsetting, linearization. Compress PDF — Size-targeted compression (100 KB, 200 KB, 1 MB targets) for upload limits. Clean Metadata — Strip creator info and revision history before publishing. OCR PDF — Add a text layer to scanned PDFs before optimizing. Merge PDF — Combine assets before final optimization pass. Split PDF — Break large optimized PDFs into smaller per-chapter files.