Compress any image to an exact file size — 50 KB, 200 KB, whatever the form demands — and exact pixel dimensions too (600×600, 200×230…). Guaranteed under the limit at the best quality that fits. Need it as a PDF? Pick PDF output and the finished PDF fits the limit too — several images can even combine into one multi-page PDF under a single cap. Already have a PDF that’s too big? Drop it in and it’s recompressed under the cap, page by page — several at once works too (each to its own target), or tick Combine to merge PDFs and images into one PDF under a single cap. Drop a whole folder for batch mode + ZIP download. 100% in your browser: nothing is uploaded.
No. PixFit runs entirely in your browser — the photo is decoded, resized and re-encoded locally and never leaves your device. Load the page, turn off Wi-Fi, and it still works.
It binary-searches the encoder's quality setting for the highest quality that fits your byte budget, and if even the lowest reasonable quality is too big, it scales the image down and searches again. The result is always at or under your target — never over.
Yes — many forms demand both, e.g. “200×230 px, max 50 KB”. Put 200x230 in the “Exact size” field and the output will be exactly those dimensions and under the byte limit (only quality is searched; dimensions are never touched). If the original's aspect ratio differs, PixFit crops to match — centered by default, and a draggable preview appears so you can choose exactly what's kept (in batch mode crops stay centered). If the source is smaller than the requested size it gets upscaled, with a warning, because the form won't accept anything else.
Type the range into the target field: 20-50 KB. PixFit still finds the best quality under the maximum, and if that best encode lands below the minimum (common for small images — a 140×60 signature at top quality is only ~5 KB), it pads the JPEG up to the floor with a comment segment. That's the mechanism the JPEG spec provides for exactly this: the file says in plain text that it's padding, no pixels change, and upload portals accept it. Padding works for JPEG output; exam and application portals that enforce minimums want JPG anyway.
Yes. Put the number in the “DPI label” field and PixFit writes it into the JPEG's JFIF header as the scan resolution (dots per inch) — the field portals and document scanners read. Be clear about what this is: DPI in a digital file is a label, not a property of the pixels. A 200×230-pixel image is 200×230 pixels at any DPI; what the label changes is the print-size arithmetic (200 DPI means “treat 200 pixels as one inch”). Specs like “3.5×4.5 cm at 200 DPI” are really telling you the pixel count — but if a portal checks the header field too, this sets it. JPEG output only. And if you only want the label changed — no re-encode, no resize — drop a JPEG in with the DPI field set and use the label-only button that appears with the result: it edits the JFIF density field (and any existing EXIF resolution tags, so the two agree) in place, leaving every other byte of your original file untouched. Dedicated pages: 200, 300 and 600 DPI.
Depends on how hard the squeeze is. A 4000×3000 phone photo into 200 KB looks fine; into 20 KB it will be visibly soft, because PixFit has to shrink it to keep artifacts acceptable. Two tips: use the max-edge field if the destination only displays a small image anyway, and pick WebP if the site accepts it — WebP fits noticeably more quality into the same bytes than JPEG.
Yes — drop several files (or select multiple in the picker, up to 100 files / 500 MB) and every one is compressed to the same target, with a per-file result table and individual Save buttons. “Download all” packs everything into a ZIP, built in your browser like everything else. Files that can't be decoded or can't fit the target are listed, not silently dropped. PDFs can ride along in the batch: each one is recompressed page by page to the same target and comes back as a PDF on its own row (see the PDF question below for the honest tradeoff). Handy for photo batches going to a listing site or CMS with a per-image cap.
Yes — the signature pad (also reachable via “draw a signature” in the drop zone) lets you sign with a finger, stylus or mouse in black or blue ink. Download it as a transparent PNG for documents, or press Use signature to feed the drawing straight into the fitter: it's trimmed, letterboxed on white to match your Exact size field so no stroke is cropped off, then fitted to the byte window — padding floors and DPI label included. One honest note: many exam notifications say “scanned signature,” meaning ink on paper — when the wording is strict, sign on paper, photograph it, and drop the photo in instead (see the next question).
Yes. Some portals — Kerala PSC's Thulasi is the best-known — require the candidate's name and the date the photograph was taken printed on the photo itself, in two lines of black text on a white strip at the bottom. Fill in the Print on photo fields in the options bar and PixFit draws that strip on the output before fitting it to your byte target, so the finished file has the label and the right size in one pass. Use the real date the photo was taken — the label documents the photo's age, and portals that require it treat it as a declaration. The text is drawn locally, applies to single photos only (batch mode ignores it), and what you type is never stored anywhere — not even in this browser's storage.
Yes. Drop the photo in and tick Signature photo cleanup in the options bar. PixFit finds the ink with an adaptive threshold (computed locally around every pixel, so uneven phone-photo lighting and paper shadows don't fool it), trims tight to the strokes with a small margin, erases stray specks, and puts the ink on a genuinely pure white background — the gray paper tint portals reject is gone. Pen colour is kept: blue ink stays blue, and faint strokes are darkened enough to read. With an Exact size set (say 300×80 or SSC's 6×2 cm strip), the trimmed ink is letterboxed to that shape so no stroke is ever cropped off, then fitted to your byte window like any other image — minimum-size floors and the DPI label included. Check the preview before uploading: if the photo has hard shadows or the paper doesn't fill the frame, the cleanup can grab the wrong thing — retake in even light and it does much better. Everything runs in this browser; the signature never leaves your device.
Yes. Pick PDF as the output format. Portals often demand documents as “PDF, max 200 KB” while what you have is a photo of the document — PixFit compresses the image to fit and wraps it into a one-page PDF in the same pass, so the finished PDF (not just the image inside) is guaranteed at or under your target. The JPEG is embedded losslessly — the PDF wrapper adds no second re-encode. Minimum sizes (“100 KB to 300 KB”) work too, and the DPI field sets the page's printed size (default 96 DPI). Exact pixel dimensions apply to the embedded image. Several images? Drop them together and tick Combine into one PDF: each image becomes a page of a single PDF that fits the byte target as a whole — pages share the budget, so a small page hands its spare bytes to a detailed one. Existing PDFs can join the merge too: drop them into the same batch and each of their pages becomes a page of the combined PDF (as a picture — text stops being selectable; each page keeps its printed size). Dedicated pages: under 100 KB, 200 KB, 500 KB.
Yes — drop the PDF straight into the drop zone. Every page is rendered locally (by pdf.js, Mozilla's PDF renderer, ~1.8 MB fetched from this site the first time you drop one), re-encoded as a JPEG, and reassembled into a PDF guaranteed at or under your target — the pages share the byte budget, so a simple page hands its spare bytes to a detailed one, and every page keeps its exact printed size. Minimum sizes (“50 KB to 300 KB”) work here too. Be clear about the tradeoff: the output contains pictures of your pages — text stops being selectable and searchable, and links, form fields and digital signatures don't survive. For a scanned PDF that changes nothing real; for a text-born PDF, only do this when the upload form cares about bytes, not text. Password-protected PDFs need the password removed first. Several PDFs at once work too: drop them together (images can ride along in the same batch) and each PDF comes back recompressed to the target on its own row, with a ZIP for the lot — or tick Combine into one PDF to merge everything you dropped (PDFs and images alike) into a single PDF that fits the target as a whole. Dedicated pages: compress a PDF to 100 KB, 200 KB, 300 KB, 500 KB.
It's gone. Re-encoding through a canvas drops EXIF, GPS location, camera serial numbers — everything. (Rotation is applied to the pixels first, so photos don't turn sideways.) If you want to remove metadata without recompressing, use PixWash, which strips it at the byte level with zero quality loss.
Input: anything your browser can decode — JPEG, PNG, WebP, AVIF, GIF, BMP — plus HEIC/HEIF from iPhones, and existing PDFs (recompressed page by page, see above). Browsers can't open HEIC themselves, so the first time you drop one, PixFit fetches a ~1 MB decoder (libheif compiled to WebAssembly, served from this site) and decodes it locally — the photo still never leaves your device. Output: JPEG (default, accepted everywhere), WebP (smaller, accepted by most modern sites) or a PDF that fits the limit. Transparent PNGs get a white background in JPEG and PDF output — JPEG has no transparency; choose WebP to keep it.
Storage and bandwidth cost the operator per byte, and many older systems hard-fail on big files. Application portals, government forms, job sites and CMSs commonly cap photos at 20 KB–2 MB — usually far below what a modern phone camera produces, which is why this tool exists.