Exact-Size PDF & Image Optimizer

Sooner or later almost everyone meets an upload form that refuses a perfectly good file. A job application wants a CV under 1 MB, an exam registration wants a photo under 50 KB and a signature under 20 KB, a visa portal wants scanned documents under 500 KB. The file looks fine on screen, but the number is wrong. Getting it right without ruining the image or document comes down to understanding what compression actually does, how pixel dimensions drive file size, how a PDF is built, and how upload portals check what you send them. This guide covers each of those in turn.

Lossless and lossy compression: two different promises

Every compression method makes one of two promises. Lossless compression promises that when the file is opened, every bit comes back exactly as it was. Lossy compression promises only that the result will look or sound close enough, and throws away detail it predicts you will not notice. That difference explains why some files shrink dramatically and others barely move.

How PNG stays lossless. A PNG image is compressed in two stages. First, each row of pixels passes through a prediction filter. Filters such as Sub, Up, Average and Paeth replace each pixel with the difference between it and a guess based on its neighbours. In flat areas like a white background or a block of solid colour, those differences are mostly zero. Second, the filtered data is packed with DEFLATE, the same algorithm used in ZIP files, which combines LZ77 (replacing repeated sequences with short back-references) and Huffman coding (giving common values shorter codes). Screenshots, logos and diagrams have long runs of identical pixels, so they compress very well. Photographs are full of fine noise where no two neighbouring pixels match, so a lossless PNG of a photo is often several times larger than a good JPEG of the same picture.

How JPEG trades detail for size. JPEG takes a different route. It converts the image from RGB into YCbCr, which separates brightness (luma) from colour (chroma). Human vision is far more sensitive to brightness than to colour, so most encoders store the colour channels at half resolution in both directions, a step called 4:2:0 chroma subsampling, which removes half of all the data before any real compression begins. The image is then cut into 8 × 8 pixel blocks, and each block is transformed with the discrete cosine transform (DCT) into a set of frequency coefficients, from smooth gradients to fine texture. The crucial lossy step is quantization: each coefficient is divided by a value from a quantization table and rounded. High-frequency detail gets divided by large numbers and usually rounds to zero. The “quality” setting you see in editors simply scales those tables. Finally, the surviving coefficients are reordered in a zig-zag pattern, run-length encoded and Huffman coded.

This design produces the artefacts most people recognise: visible 8 × 8 blocks in smooth skies, and “ringing” halos around sharp text and edges at low quality. It also explains why file size does not fall evenly as quality drops. Going from quality 100 to about 85 often halves the file with almost no visible change, while going from 50 to 30 saves comparatively little and looks much worse. Each time a JPEG is opened and saved again, quantization is applied again, so repeatedly re-saving a JPEG slowly degrades it. That is why it is best to compress from the highest-quality original you have, once, to the size you need.

Raster scaling: pixels are the real budget

A raster image is a grid of pixels, and file size follows the number of pixels more closely than anything else. Halving both the width and the height leaves a quarter of the pixels, and for a given quality the file shrinks roughly in proportion. A modern phone photo of 4000 × 3000 pixels holds 12 million pixels; an ID photo requirement of, say, 600 × 800 pixels needs fewer than half a million. Trying to push a 12-megapixel photo under 50 KB by quality alone produces a smeared, blocky mess, while scaling it down first leaves plenty of bytes for detail.

Scaling, or resampling, calculates new pixel values from the old ones. Simple methods like nearest-neighbour just pick one source pixel and create jagged edges. Bilinear and bicubic filters blend neighbouring pixels for smoother results, and Lanczos uses a wider window for extra sharpness. Shrinking an image by a large factor in a single step can skip over detail and cause shimmering moiré patterns, so careful tools reduce the size in stages, halving it until it is close to the final dimensions and then making one last precise step. This tool works that way.

It is also worth knowing that DPI is not a size. A 1200 × 1600 pixel image is the same file whether its header says 72 DPI or 300 DPI; the DPI value only tells printers how large to print it. When a portal asks for “300 DPI”, it usually means it wants enough pixels to print at a certain physical size. Check the pixel dimensions it asks for, if any, rather than the DPI field.

Inside a PDF: why some shrink and others refuse

A PDF is a container of numbered objects: page descriptions, fonts, images, annotations and metadata, held together by a cross-reference table. Text and vector drawings are stored as compact drawing instructions, so a 20-page text-only report can be well under 200 KB. What makes PDFs heavy is almost always images: scanned pages, photos and screenshots, each stored as its own compressed stream. A scanned document is effectively a stack of photographs, one per page.

There are three broad ways to make a PDF smaller. The first is lossless restructuring: packing many small objects into compressed object streams, dropping unused objects, and removing embedded metadata. This keeps text selectable, searchable and accessible, and it is what this tool tries first. On files dominated by images, though, it may save only a few per cent. The second is recompressing the embedded images: decoding each photo or scan stored inside the PDF and saving it again as a smaller JPEG, while the text, fonts, links and form fields around it stay exactly as they were. This is usually where the big savings come from, and it is what this tool tries next. The third is re-rendering: drawing each page as an image at a chosen resolution and storing it as a JPEG. That can shrink a 15 MB scan to a few hundred kilobytes, but the pages become pictures. Text can no longer be selected or searched, links stop working and screen readers cannot read the content. At around 150 pixels per inch, ordinary printed text stays crisp on screen; around 100 it remains readable; below about 72, small print and fine lines start to break down. This tool only falls back to re-rendering when the first two methods cannot reach your limit, picks the highest resolution and quality that fit, and tells you which method it used so you can decide whether the trade-off is acceptable.

How upload portals check your file

Government services, universities, recruitment systems and banks set strict limits for practical reasons: they store millions of documents, serve them to reviewers on slow connections, and often run on older systems with fixed database fields. Most portals check some combination of the following, and a file that fails any one of them is rejected:

• Maximum size. Checked in bytes, often with no tolerance at all. A file one byte over is rejected just as firmly as one a megabyte over. Some portals also set a minimum size, to catch blank or corrupted uploads.
• File type. Many portals look at the file’s actual contents, its so-called magic bytes, rather than trusting the extension. Renaming “photo.png” to “photo.jpg” does not change the contents and may still be rejected.
• Pixel dimensions. Photo and signature fields often require exact or minimum dimensions. Compressing to a size limit should not drop below those, so check the instructions before you choose a very small target.
• Page count and readability. Document fields may limit the number of pages, and a human reviewer may reject a scan that is too blurry to read.

One more source of confusion is the kilobyte itself. Some systems define 1 KB as 1,000 bytes and others as 1,024 bytes. This tool always aims at or below the smaller of the two, so a result labelled 200 KB passes either rule.

Getting the best result from this tool

• Start from the original file. Compressing a file that has already been compressed, by this tool or any other, gives poorer results: the lost detail cannot come back, and each new pass adds fresh artefacts. If a PDF has already been through an image-based pass, its pages are pictures, so there is little left to squeeze and no text left to keep selectable. Go back to the file that came out of your word processor, scanner or camera whenever you can.
• Expect the images to take the cut. In a PDF, only the photos and scans can be made smaller without touching the text. Fonts, text and vector drawings stay exactly the same size. If a 16 MB document has to fit under 10 MB and the text and fonts take up a few of those megabytes, the images must shrink by much more than 40 per cent on their own. That is why the dashboard may report a lower JPEG quality than you expected, even though the pages still look clean at normal zoom.
• Read “Could not reach limit” as a warning, not a failure. The tool will not shrink pages or embedded images below roughly 48 pixels per inch on a standard page, because text in them stops being readable. When a limit is out of reach, it offers the smallest readable version instead. The practical fixes are to remove pages the reviewer does not need, split the document into parts if the portal accepts several files, or check whether a larger limit applies to your document type.
• Phone photos stay the right way up. Phones often save photos sideways and record the correct rotation in the metadata. The tool applies that rotation before it removes the metadata, so the compressed photo is upright and carries no hidden location data.
• Change the limit as often as you like. Every time you type a new limit or pick a preset, the tool starts again from your original file, not from the previous result, so trying a smaller size and then going back costs no quality.

A reliable workflow for any upload limit

1. Start from the best original you have: the camera photo rather than a messaging-app copy, or the digital PDF rather than a scan of a printout.
2. Read the portal’s requirements for size, file type, dimensions and page count, and write them down before you start.
3. Crop away anything the reviewer does not need, such as table edges around a scanned document, because every pixel you remove is budget you can spend on clarity.
4. Enter the exact maximum size in this tool and let it find the best quality that fits.
5. Open the downloaded file and check that every word and number is legible at normal zoom.
6. If the result looks too soft, try scanning at a lower resolution in greyscale, or splitting a long document if the portal allows several files.
7. Keep the original. Compression is a one-way process, and you may need a different size for the next form.

Handled this way, a file size limit stops being a frustrating wall and becomes a simple budget: decide what the reviewer needs to see, spend the bytes on that, and let the rest go.