Compress a PDF without uploading it

SQLViz · September 2026

You can shrink a PDF without sending it to anyone. Modern browsers decode and re-encode images natively, so the whole job can run inside a tab on your own machine. For a payslip, a medical record or a signed contract, that is usually the deciding factor.

It is worth being clear about the compromise, though. A browser compressor does not produce the same output as a server running Ghostscript. Knowing what each one actually does is the difference between a file that shrinks well and a file you should not have touched. You can test it on your own documents with the PDF tools.

Why PDFs get big

A PDF is a container, not an image format. It stores the instructions for drawing each page, and those instructions can be heavy:

• Full-resolution embedded images. A phone scan keeps every pixel. A 4000 x 3000 photo at three bytes per pixel is roughly 36 MB of raw data before any compression, and most of that detail is wasted on a printed A4 page.
• Duplicated fonts. Fonts are embedded as subsets, and they are not always shared. Merge documents produced by three different tools and you can carry the same typeface three times over.
• Scans stored page by page. Forty scanned sheets are forty independent images. The white background and the scanner noise repeat on every one, and that redundancy is never exploited.
• Leftover objects. Removed fields, unused resources and old revision data can survive editing and sit in the file doing nothing.

What actually reduces size

Only a few things move the needle:

• Downsampling images. Replacing a 300 dpi image with a 150 dpi one removes three quarters of the pixels. This is the single biggest lever for scanned files.
• Re-encoding as JPEG. Storing an image as a JPEG at reasonable quality is far smaller than the lossless pixel data sitting inside a typical PDF.
• Dropping unused objects. Removing orphaned resources and duplicate fonts, which is the work Ghostscript and qpdf are built for.

Text-only PDFs are already compact. A 30-page report with no images is often under 500 KB, and there is little left to remove. The files that shrink dramatically are almost always scans and image-heavy layouts.

How a browser-based compressor works

With no server involved, JavaScript has to do the work. The approach used by client-side tools is to render each page to an image in a canvas, re-encode that image as a JPEG, then rebuild the PDF around the result.

That gives you one strong lever, image re-encoding, and one real limitation. A browser tab cannot perform the object-level surgery Ghostscript does, so it cannot strip duplicate fonts or unused resources the way a server tool can. On a scan-heavy file the two approaches land in a similar place. On a text-heavy file, a server tool can often do better with no visible loss at all.

The trade-off nobody mentions

If your PDF has selectable text, that text becomes an image. After compression you can no longer select it, copy it, search it, or have a screen reader read it. The words are pixels.

That is fine for some documents and a bad idea for others.

Acceptable: scans, brochures, menus, flyers, signed forms, and anything you are sending once and will not need to search later.

Not acceptable: contracts you may need to search for one clause in three years, invoices you will feed to accounting software, PDFs you plan to keep editing, or anything that has to stay accessible.

If the words matter, keep an uncompressed copy. For sharing a preview, exporting the pages as images is often a better fit than compressing the whole document, which is the job covered in PDF to JPG without sending the file anywhere.

Choosing a quality setting

Most compressors expose a JPEG quality level. Start around 70. That is usually indistinguishable from the original at 100% zoom on screen. Push down to 50 for scans where the content is plain text and you accept slightly rough edges around the letters. Below 40 you get visible blockiness around text and colour banding in gradients, which looks worse than the file size saving is worth.

Check the first page at 100% zoom before accepting the result. JPEG quality fails first on small text, thin lines and hard edges between dark and light.

A workflow that avoids regret

Never compress the only copy. Duplicate the file, compress the copy, and compare the two side by side. Keep the original until you are sure the compressed version is good enough for its purpose.

One more thing worth knowing: if the tool hands the file straight back unchanged, that is a result, not a bug. Compressors are supposed to check whether the new file is actually smaller. If re-encoding would make it bigger, the original is returned and you are told so. It usually means the PDF was already efficient, typically a text-only document that had nothing left to give.

If you are handling several documents at once, the same logic applies to merging PDFs without uploading them, and the client-side tools on sqlviz.app all work the same way: the file stays on your device and nothing is sent anywhere.