JPG to PDF Under 200KB — Free, Fast & Private
Almost nobody wants a 200 kilobyte PDF for its own sake. What they have is a form — a scholarship portal, a visa appointment site, a tender submission, an HR system, a bank's document upload — with a box that says "PDF, maximum 200 KB" and refuses everything larger without explaining why. What they also have is a phone that produces four megabyte photographs. The gap between those two numbers is a factor of twenty, and closing it is a compression problem dressed up as a conversion problem, which is why so many "image to PDF" tools leave you exactly where you started: they hand back a nine megabyte document and consider the job done. This page starts from the limit instead of ending at it. The target above is already set to 200 KB, the images you drop in are compressed toward that number before they are embedded, and the document that comes out is weighed before you are shown anything. Nothing is uploaded at any point — the images are read, decoded, encoded and assembled by JavaScript running in this tab, so the bank statement or the passport scan never leaves your machine.
What the tool actually does with the number
The 200 KB is a budget for the finished file, not for the pictures inside it, and those are different things. A PDF is a container: on top of the image data it carries an object table, a page tree, a content stream and an image dictionary for every page, plus a cross-reference table and a trailer. On a ten page document that structure is several kilobytes, and a tool that budgets 200 KB of image bytes ships a 207 KB file to a portal that rejects at 200. So the budget is split. The container is estimated first, the remainder is shared out across your images in proportion to how many pixels each one has — a twelve megapixel photograph needs more bytes to look acceptable than a small screenshot does, and giving them equal shares starves one to feed the other. Each image is then compressed to its share by the same byte-target search the MiniPx compressor uses: a probe at high quality, a probe at the lowest quality the format allows, and then an interpolating search between them for the highest quality that still fits. Images that come in under their share donate the surplus to the images after them, which costs nothing and means the whole budget gets used rather than wasted.
Estimated once, then measured
An estimate of the container overhead is a guess, and this tool does not ship guesses. Once the first version of the document exists, its real size is known and so is the total size of the images inside it; the difference between those two numbers is the exact overhead, measured rather than assumed. If the first attempt came in under 200 KB, that is the end of it and you get the file. If it overshot, the measured overhead replaces the estimate and the images are re-fitted against a corrected budget. This almost always lands on the second attempt, because after the first one the only remaining error is a few bytes of cross-reference offsets. There is a third attempt available and a hard stop after it. Images that have already been squeezed as far as the format goes are not re-compressed on later attempts, since their bytes cannot move and the work would only confirm what the previous attempt established. If every image is in that state, the tool stops immediately rather than grinding through passes that cannot change the answer.
Hitting a hard limit costs quality, and here is where it comes from
This is the part most size-limit tools go quiet about. Two hundred kilobytes is a small amount of data for a photograph, and a small amount split across five photographs is smaller still. The first thing spent is JPEG quality: the search walks the quality dial down until the file fits, and on a single clean scan of a typed page you will very likely not see the difference. Push harder — several camera photos, or one very detailed one — and you start to see what lossy compression looks like when it is working hard: soft blocking in flat areas like skies and walls, a slight mushiness around text and edges, colour banding in gradients. If quality alone cannot get there, the image is reduced in pixel dimensions as well, in steps, and the page keeps its original size so the smaller picture is scaled back up to fill it. That is a genuine loss of resolution and it is the last resort rather than the first. One more consequence worth knowing before you start: every page is embedded as JPEG, because JPEG is the only format with a continuous quality dial and therefore the only one a byte target can steer. A PNG with a transparent background will come out flattened onto white.
When 200 KB is not reachable, the tool says so
Sometimes the answer is no. Fifteen high resolution photographs cannot become a 200 KB PDF that is worth having, and past some point they cannot become one at all — the smallest JPEG each page can be, multiplied by the number of pages, plus the container, is simply more than 200 kilobytes. When that happens you get a red notice above the download button stating the target was not reached, the size the file actually is, and that an upload form enforcing the limit will refuse it. The number shown is the real one: a 214 KB result is reported as 214 KB, never rounded down to "about 200 KB" and never quietly presented as a success. You still get the file, because the smallest version of the document is usually still useful and deleting your work would be a strange way to deliver bad news. What the notice suggests is what actually helps at that point, which is not more compression: fewer pages, or smaller source images. The download button carries the finished size whether the target was met or missed, so there is never a version of this screen where you cannot see what you are about to download.
Why it does not run forever on a big batch
Each image's fit is a search, and each search can spend up to sixteen encodes before it stops. Left uncapped, twenty images across three attempts would be nearly a thousand encodes, which on a phone is not a progress bar, it is a dead tab. So there are two ceilings and whichever bites first wins: at most three assemblies of the whole document, and at most forty image searches across the entire build. For one to thirteen images — the great majority of real batches — all three attempts fit inside that allowance. For twenty images, the first attempt spends twenty searches and the second spends the twenty that remain, so the third is refused before it starts rather than abandoned halfway through. That trade is deliberate, and it is a cheap one, because by the second attempt the tool is working from a measured container overhead rather than an estimate and usually lands the target there anyway. The practical advice for large batches is unchanged and predates any of this: fewer pages leaves more bytes for each one.
Other limits, and turning the limit off
Two hundred kilobytes is the most common ceiling on Indian government and university portals, which is why this page is built around it, but it is not the only one anybody meets. The control above also offers 100 KB, 500 KB and 1 MB, and switching between them re-runs the whole fit — you are not stuck with the number the page arrived on. There is also a "No limit" option, and it is the default everywhere else on the site for a good reason: reaching a size target costs image detail, and that is not a cost to impose on somebody who never asked for it. If your form does not state a maximum, use no limit and keep your full resolution. If it states one, pick the closest option at or below it rather than aiming exactly at the number, since some portals count in decimal kilobytes and a file at 199.8 KB clears both readings comfortably.
Nothing is uploaded, including the compression
Every step described above happens in this browser tab. The images are read as bytes by JavaScript, decoded by your browser, re-encoded by a compression engine compiled to WebAssembly and running on your own processor, and assembled into a PDF by jsPDF in the same page. No request carrying image or document data is made, which you are welcome to confirm in your browser's network inspector while a build is running. That matters more here than on most tools, because the documents people put through a 200 KB limit are exactly the sensitive ones: identity documents, degree certificates, bank statements, medical letters, signed forms. It also means there is no queue, no account, no watermark, no daily cap and no upload size ceiling beyond what your own device can decode. The trade is that the work runs on your hardware, so a batch of large photographs will take longer on a phone than on a laptop and will make a laptop fan audible. That is the honest cost of not handing your paperwork to a server.