Ghostscript is a free, open-source PostScript and PDF interpreter that rewrites PDFs through its built-in pdfwrite device, and the typical recipe for using it to compress a PDF is a single command that downsamples images, recompresses streams, and re-embeds fonts in one pass. The interpreter reads the input PDF page by page, classifies the objects inside it, and emits a brand-new file rather than editing the source in place, which is why its byte savings can be substantial for image-heavy scans but modest for text-only documents. The recipe itself is short, yet the gap between "I want a smaller PDF" and "I have Ghostscript installed, on my PATH, and the right switches memorised" is wide enough that many readers end up looking for a simpler path before they ever type the command. For PDFs whose bulk comes from embedded photos, that simpler path is a tab-based tool that opens the file in memory, finds the JPGs inside it, and re-encodes only the ones it can safely make smaller before handing back a verified result.
What the Ghostscript Command Line Actually Changes
The reason Ghostscript can shrink PDFs that other tools barely touch is that it does not edit the file in place. With -sDEVICE=pdfwrite set, every page is parsed, the objects inside it are classified by type, and a fresh PDF is produced from the parsed result. The output device honours a family of preset profiles that bundle several switches at once, so you usually do not have to tune each one individually.
| Preset | Switch | Image target | Typical use |
|---|---|---|---|
| screen | -dPDFSETTINGS=/screen | ~72 dpi, heavy JPEG | On-screen viewing only |
| ebook | -dPDFSETTINGS=/ebook | ~150 dpi, medium JPEG | E-readers and casual sharing |
| printer | -dPDFSETTINGS=/printer | ~300 dpi, light JPEG | Office printing |
| prepress | -dPDFSETTINGS=/prepress | ~300 dpi, near-lossless | Print production |
Behind the scenes each preset expands into a longer list of switches that control image downsampling, JPEG quality, font embedding policy, and stream filters. A typical screen-level command looks like this:
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/screen -dNOPAUSE -dBATCH -sOutputFile=out.pdf in.pdf
The -dNOPAUSE and -dBATCH flags let Ghostscript run unattended, and the output flag points at the new file. If you do not want the preset defaults you can override individual switches — -dColorImageResolution=72, -dGrayImageResolution=72, -dMonoImageResolution=150, -dJPEGQ=70 — to dial in your own trade-off between sharpness and size.
Where the Command-Line Approach Gets in the Way
The first obstacle is install friction. On Debian and Ubuntu the package is ghostscript and pulls in a handful of dependencies; on Fedora and RHEL the equivalent command installs it through dnf; on Windows you download a GPL release from the project's site and add its bin folder to your PATH. None of that is hard for someone comfortable with a terminal, but it is friction for anyone who just wants a smaller file before attaching it to an email.
The second obstacle is what a full re-render means for the document. Because Ghostscript parses the input and writes a new PDF, things like embedded ICC color profiles, form field states, signed signature dictionaries, and some annotation types can change in subtle or surprising ways. For a scan of a printed report that is irrelevant. For an audited PDF, a contract with signature fields, or a print-ready file that has to keep its color management intact, it is a real risk that the rewritten file no longer matches the original. The Compress PDF tool takes the opposite approach and limits itself to one specific class of object so the rest of the document is left exactly as it was.
The third obstacle is feedback. The command-line recipe tells you when it finishes, but it does not show you a before-and-after preview, and it does not verify that the rewritten PDF still opens cleanly in the viewer your audience uses. If a switch combination produces a malformed file, you usually find out at the receiving end. That is fine for power users, but it pushes most readers toward a path that surfaces problems before they share the file.
Compress a PDF Locally in Your Browser Instead
For PDFs whose bulk comes from embedded photos or scanned pages, a much smaller step reaches the same end: open Compress PDF in a browser tab, drop in the file, and let the tab find and re-encode the JPGs inside it. The PDF is read into memory, the image objects are enumerated, and only the ones that meet a strict eligibility test are replaced with a smaller re-encoded version. The source file never leaves the browser tab; reading, decoding, re-encoding, and assembly all run locally, and the result is reopened with a PDF viewer before any download link is exposed.
The eligibility rules are deliberately narrow. The tool only acts on unmasked DCTDecode JPG streams that use DeviceRGB or DeviceGray color data and that have no decode parameters. That rules out JPEG 2000 (JPX), CMYK, Indexed color, masked images, ImageMask images, and any image with a decode array — those are skipped rather than re-encoded with a guess. If a candidate re-encoded JPG is not actually smaller than its original byte stream, the original image is kept. If no eligible image can be made smaller, the tool returns an honest error instead of handing back a file with a misleading name. Per-run limits include one PDF up to 25 MB, up to 80 eligible image objects, and a combined decoded image size of 100 megapixels; documents above any of those bounds are not accepted by this version of the tool.
How to Compress a PDF in Your Browser
- Choose one local PDF up to 25 MB. Larger files are rejected at the input stage, so size it down first if you are over the limit.
- Open Compress PDF and select the file. Nothing is uploaded; the bytes are loaded into the current tab.
- Wait while the tool walks the image XObjects inside the PDF and re-encodes only the eligible JPGs at a balanced quality and a maximum dimension of 1400 px on the longest side.
- Read the reported input and output sizes shown after the run. If the output is not smaller than the input, no download is offered.
- Download the verified PDF only after you have compared the two sizes and confirmed the result is what you wanted. The original file is left untouched on disk.
The verification step is the part most command-line workflows skip. After the eligible JPGs are replaced and the new PDF is written, it is reopened with a viewer based on Mozilla's PDF.js library to confirm the page count still matches before the download link is shown. That guards against the case where a re-encoded image stream would have produced a malformed PDF and the user would otherwise have found out only when the file failed to open somewhere downstream.
What the Browser Tool Changes and What It Leaves Alone
The trade-off the tool accepts is straightforward: smaller embedded JPGs in exchange for leaving the rest of the document structure alone. Page content, page count, text, links, vector objects, form fields, annotations, and metadata are preserved because the tool only rewrites specific image stream payloads at their existing indirect references and never rebuilds the surrounding page tree. Unsupported image objects are skipped rather than converted, so a PDF that mixes photos with logos in CMYK or vector diagrams ends up smaller on the photo pages and unchanged on the rest.
That also means the tool has clear no-go cases. A text-only PDF — a contract, an essay, a report exported from a word processor with no embedded photos — usually cannot shrink, because there are no eligible JPGs to re-encode. A document dominated by JPEG 2000 scans will not shrink for the same reason: JPXDecode is on the skip list. For those cases the file size depends on image format and PDF overhead rather than anything the tool can act on, and the honest answer is that Ghostscript or a specialist desktop PDF optimizer is the right tool, not a smaller-step alternative.
When Ghostscript or a Desktop Optimizer Is Still the Better Choice
Ghostscript earns its place back whenever the browser tool's narrow eligibility list leaves too much fat on the table. If the PDF is text-heavy, dominated by JPEG 2000, uses CMYK color, or has to be reproduced with archival conformance, the pdfwrite device at /printer or /prepress settings can rewrite the streams, flatten transparency, and re-embed fonts in ways a JPG-only tool never will. The install-and-terminal cost is the price of that reach.
For image-heavy PDFs that just need to fit under an attachment size limit, the order of operations is usually: try Compress PDF first because it runs locally and finishes in seconds, and only fall back to a Ghostscript command or a desktop optimizer if the result is still too large. Keep the original file, inspect the output in your usual PDF viewer, and compare a couple of pages at 100% zoom before sharing the smaller copy — that quick check catches the rare case where a re-encoded photo softens more than expected and you would rather keep the source bytes. For more on the browser-first approach and what changes when you stay inside a single tab, see how to compress a PDF easily in your browser.
For a deeper look, see Use Preview to Compress PDF: Try a Browser Alternative.