What "lossless" would really require
True lossless compression means the file gets smaller while every pixel and every character stays byte-for-byte identical. For a PDF that already contains JPEG images (which almost all scanned and photographed PDFs do), there usually isn't much room left for this — JPEG itself is already a compressed format, and compressing an already-compressed image again rarely saves much without also throwing away picture data. The gains people actually experience when they "compress without losing quality" come from somewhere else: removing redundant or unnecessary data that was never part of what the reader sees — unused embedded fonts, excess metadata, images that were saved at a far higher resolution than the document will ever display at.
A more honest goal than "lossless" is visually equivalent: a result where nobody would notice the difference at a normal reading zoom, even though, measured pixel by pixel, something did change.
Two different tools, two different trade-offs
High-quality compression sends the file to a server running Ghostscript with its "ebook" preset: embedded images are resampled to roughly 150 dpi, while text and vector drawings are left exactly as they are. For a report, CV or contract — mostly text, maybe a logo or a couple of photos — this is usually the closest thing to "no visible loss," because the part doing most of the reading (the text) isn't touched at all.
Compress and Compress to target size work differently: every page is rendered as a JPG image and reassembled into a new PDF. This is the right tool when the source is already a scan or a photograph — there's no text layer to protect — but it is a real loss for anything that started as a digital document, because it throws away the searchable text layer and replaces sharp vector text with a picture of text.
Rule of thumb: if you can select and copy the text in the original PDF, use high-quality compression first. If the file is already a scan or photo, go straight to a target-size or standard compression pass.
When "high quality" and "small" pull against each other
A ten-page report exported from Word with a handful of embedded photos might start at 8 MB. Ghostscript's ebook preset can often bring that down to somewhere around 1–2 MB while keeping every word of text sharp, because most of the original 8 MB was photo resolution the page never needed. But pushing the same file under 1 MB usually means something has to give beyond what resampling alone can fix — reducing the number or resolution of the photos before they're placed in the document, or accepting a lower image quality setting that starts to show as softness in those images specifically. At that point, "no loss" and "under 1 MB" stop being simultaneously achievable, and the honest move is to decide which photos actually need to stay at higher quality, if any.
Email limits are a common real-world reason for a small target
A frequent source of a strict size requirement is simply "it has to go through email." Gmail's documented limit for sending is 25 MB combined per message. Attachments are base64-encoded for transport, which adds roughly 33 percent overhead — so a 20 MB file on disk becomes about 27 MB once encoded, already over the 25 MB cap. A safer practical target for anything going by email is closer to 18 MB of actual file size, not 25.
For a single PDF attachment well under that, high-quality compression on a digital document, or a target-size pass on a scanned one, will usually get there without noticeable loss — email limits are generous compared to the 100–500 KB range that strict upload portals ask for.
A simple decision order
- Is the text in the PDF selectable right now? If yes, try high-quality compression first — it's the closest thing to lossless available here.
- Still too big? Check whether unnecessary pages or very large embedded images are the cause before reaching for a harsher setting.
- Is the source a scan or photograph, with no text layer to protect? Use Compress to target size directly and accept that this method rebuilds the page as an image.
- Is the real constraint an email attachment limit? Aim for roughly 18 MB of actual file size, not the stated 25 MB, to leave room for encoding overhead.
Quick checklist
- "Lossless" and "visually unchanged" are different claims — aim for the second, honestly.
- Selectable text → high-quality server compression, not an image-based tool.
- A scan or photo → target-size compression is the appropriate, not inferior, choice.
- Email limit? Target well under the stated cap to allow for encoding overhead.
- If quality and size genuinely conflict, decide what has to give instead of hoping a setting will resolve it invisibly.
Sources for the Gmail attachment figures: Gmail Attachment Size Limits & Workarounds · How Big a File Can Gmail Send?