Most oversized PDFs are large for one reason. They carry scanner output or photographs at far higher resolution than anyone will ever look at. A 300 dpi colour scan of a twenty page contract routinely lands at 40 megabytes, and almost all of that is pixel data that adds nothing on screen. Re encoding at half the resolution and quality 70 usually brings the same file down to two or three megabytes.
Nothing is uploaded. PDF.js rasterises the pages, the canvas element encodes each one, and pdf-lib assembles the replacement, all inside the tab. That means you can compress PDF files you would never hand to a website, such as a payslip or a medical scan, and there is no size cap beyond the memory your browser can allocate.
When you should compress PDF files and when you should not
Rasterising is the right answer when the document is already made of pixels. Scans, photographed receipts and exported slide decks lose almost nothing visible and shed most of their weight. It is the wrong answer when the value of the file is in its live text, because a rebuilt page is an image, and an image cannot be searched, selected or read aloud by a screen reader.
Judge by what happens to the file next. Something being emailed, uploaded to a portal with a 10 megabyte cap or archived for reference is a good candidate. A contract a lawyer will search through, or a form somebody still has to fill in, should keep its original structure.
- Compress PDF scans and photographed paperwork, where every page is already an image.
- Compress exported presentations, where each slide is effectively one large graphic.
- Keep the original when the text has to stay selectable or searchable.
- Keep the original when the file contains form fields somebody needs to complete.
- Delete unneeded pages first, since removing five of twenty saves a quarter of the size at no quality cost.
What rasterising does to text, links and form fields
The tool draws each page exactly as your browser displays it, then stores that drawing as a photograph of the page. Everything you can see survives, including fonts, colours, tables and signatures. Everything you cannot see does not. Selectable text becomes pixels, hyperlinks stop being clickable, bookmarks are not carried across and form fields are flattened into their painted appearance.
Text that was crisp vector outlines becomes pixels, so it softens when zoomed. At 150 dpi that is invisible on screen and acceptable in print. Below about 100 dpi small type looks muddy.
Choosing your pdf compression settings
Two controls decide the outcome. Resolution sets how many pixels each page is drawn with, and quality sets how hard the JPEG encoder squeezes them. Resolution matters more, because halving it removes three quarters of the pixels before the encoder starts.
For a document that will only be read on screen, 120 to 150 dpi is the sweet spot. For anything that may be printed, stay at 200. Quality between 65 and 80 covers nearly every case, since the eight by eight blocks JPEG works in only become visible below about 60.
The panel reports the before and after size with the percentage saved, so the practical method is to run once at the defaults, read the number, and only reach lower if the result is still too big for its destination.
How this compress PDF tool works in your browser
Three pieces do the work and none of them is a server. PDF.js parses the document and renders each page onto a canvas at the scale implied by your chosen resolution. The canvas toBlob method encodes that canvas as JPEG. Then pdf-lib embeds the image into a new page of exactly the original dimensions, so the finished document keeps the same page count and the same physical page sizes.
Because the compute is yours there is no queue, no daily limit and no retention policy to trust. The cost of that design is memory: each page exists as a full bitmap for a moment, so pages are processed one at a time and released immediately, which keeps the peak low enough for ordinary hardware.
Getting a document under a specific upload limit
Upload limits are the usual reason anyone wants to compress PDF documents at all. Email attachments commonly cap at 25 megabytes, government portals often at 10, and application forms sometimes at 2. The fastest route to a target is to change resolution first and quality second.
If a run lands close to the limit, drop the resolution one step rather than pushing quality into the fifties. Fewer pixels at a decent quality looks better than many pixels encoded badly, and it usually saves more. If you still cannot reduce pdf file size enough at 100 dpi, the document is simply longer than the limit allows and splitting it into parts is the better answer.
| Document | Before | After at 150 dpi, quality 70 | Text stays selectable |
|---|---|---|---|
| 20 page colour scan | 40 MB | 2 to 3 MB | No |
| Exported slide deck | 18 MB | 1.5 to 3 MB | No |
| Photo heavy brochure | 12 MB | 1 to 2 MB | No |
| Plain text report | 300 KB | 700 KB or more | No |
How to compress PDF documents
- 1
Add your PDF
Drop a .pdf file onto the drop area or click to choose one. The document is read on your device and never uploaded.
- 2
Pick a resolution
150 dpi suits anything read on screen. Raise it to 200 if the result may be printed.
- 3
Set the JPEG quality
Around 70 balances size against clarity. Lower values save more but make flat areas and edges look blocky.
- 4
Compress and download
Press the button, watch the per page progress, then check the reported saving before downloading.
Related tools worth bookmarking
Sources and further reading
- MDN: HTMLCanvasElement.toBlobDocuments the canvas encoder used here, including exactly how the JPEG quality argument is interpreted.developer.mozilla.org
- PDF.js projectThe Mozilla PDF renderer that parses and rasterises each page before it is re encoded.mozilla.github.io
- ISO 32000-2, the PDF specificationThe formal definition of the PDF format, including how image data is stored inside a page.iso.org
Frequently asked questions
Common questions about the compress pdf.
When you shrink a scanned document the saving is usually 80 to 95 percent, because scanner output carries far more resolution than reading requires. Files that are already efficient vector text may shrink very little, or occasionally grow, since a photograph of a text page can cost more than the text.
No. Each page is rebuilt as an image, so text becomes pixels and cannot be selected, searched or copied. That is the price of this method. Extract the text before compressing, or keep the original document alongside the smaller copy if you may need to search it.
Neither changes. The new document has the same number of pages and each page keeps the physical dimensions of the original, measured in PDF points. Only the pixel content inside the page is replaced, so printing produces the same layout on the same paper size.
Yes, because the file never leaves your device. Parsing, rendering, encoding and rebuilding all happen in the browser tab. You can confirm it by opening the network panel of your developer tools and watching a run finish without a single request carrying the document.
That happens when the original was already compact and made of vector text. Storing a page as a photograph costs more than storing a few hundred glyph references. Lower the resolution, or accept that this particular document is already about as small as it usefully gets.