Almost every upload problem on the internet comes down to the same mismatch: cameras measure in megabytes and forms measure in kilobytes. A photo straight off a modern phone weighs 3 to 6 MB, which is 3,000 to 6,000 KB in the units a form actually cares about. When that form caps a profile picture at 100 KB or a signature scan at 20 KB, you are being asked to cut the file by 97 to 99 percent. Doing that by hand in a desktop editor means exporting at a guessed quality level, checking the file size, exporting again, and repeating until you either hit the number or give up and settle for a worse-looking file than you needed. This page skips the guessing entirely: you give it a target in kilobytes, and it searches for the highest image quality that lands under that number.
The way it gets there is a binary search over JPEG quality. Instead of stepping down through quality 90, 80, 70 and hoping one of them fits, the tool encodes the image once, measures the real output size, and halves the search range every round. Because there are only 101 quality values to choose from, about seven re-encodes — each taking a few milliseconds in the browser — converge on the exact highest quality that satisfies your limit. The practical difference shows up in the result: a manual loop usually stops two or three steps lower than necessary because checking is tedious, while the search never leaves quality on the table. If the target simply cannot be reached at the current dimensions, you can let the tool step the pixel width down in small increments until the bytes fit, or lock the dimensions and get an honest report that the target is unreachable rather than a blurred file that fails the upload anyway.
One rule matters more than any setting: compress once, from the original. Every time a JPEG is saved again at a lower quality, the losses compound — gradient skies develop visible banding, text edges grow fuzzy halos, faces take on a slightly waxy look. If a file has already been through three apps and messaging platforms, each of which recompressed it, saving yet another copy on top of that debris produces exactly the mushy result people associate with compression. The fix costs nothing: go back to the original camera file or the original export, and make a single pass straight to your target. One pass at quality 70 from a clean source looks dramatically better than three stacked passes that each averaged quality 85.
There is also free weight hiding inside most photos that has nothing to do with picture quality. Cameras embed an EXIF block in every JPEG: GPS coordinates, camera model, lens settings, timestamp, sometimes a full thumbnail. That block commonly weighs 10 to 30 KB, which on a 20 KB target is bigger than the entire allowed file. Re-encoding strips it out automatically, so the output carries pixels and nothing else. That is a privacy improvement as much as a size one — a passport or ID photo uploaded with GPS data intact tells the receiving server exactly where you were standing when you took it, a fact most people never realize until it is pointed out. The original on your device keeps its metadata untouched; only the compressed copy comes out clean.
Everything on this page runs inside your browser tab. The image is decoded, re-encoded, and assembled into a download entirely on your device — no server receives a copy, and once the page has loaded the whole thing works with your connection switched off. For passport scans, ID photos, and tax documents, that is the difference between a tool you can use without thinking and one where you are handing sensitive identity documents to an unknown third-party site. There is no account, no watermark, no usage cap, and input files up to 30 MB are supported.
The rest of this page covers the arithmetic behind the tool so you can make better calls about your own images: how kilobytes and megabytes actually convert, the upload limits you are most likely to run into, what the JPEG quality number does to file size and where the sweet spots sit, when shrinking dimensions beats lowering quality, when a PNG should just become a JPG, and a workflow for handling a whole folder of images without wrecking any of them.
KB and MB: the 1024 problem that trips everyone up
File size units are not a clean 1,000-step ladder the way meters and kilometers are. Computers count in binary, so one megabyte is 1,024 kilobytes, and one gigabyte is 1,024 megabytes. A file your operating system reports as 4.2 MB is therefore about 4,300 KB, not 4,200 KB, and drive manufacturers further muddy things by labeling a '250 GB' drive with decimal gigabytes while the system displays binary ones. For everyday compression work the numbers you need are simple: a 1 MB image is roughly 1,000 KB, a 500 KB file is about half a megabyte, and anything a form expresses in MB can be multiplied by 1,000 to see it in kilobytes.
The confusion this causes is very real in form-filling situations. Someone asked for a photo 'under 500 KB' who is used to thinking in MB often uploads something that is 500 KB short of their 4 MB original — a 3.5 MB file — and cannot work out why the portal rejects it. Reading the limit in the right unit changes your expectations immediately: a 100 KB ceiling against a 4,000 KB original is a 40-fold reduction, which tells you before you start that heavy compression is coming and that quality will be the thing that gives, not dimensions alone. It also explains why the tools that ask for a number in KB are the useful ones: 'make it smaller' is not a spec, but 'under 100 KB' is.
One more practical wrinkle: operating systems and web tools report sizes with different rounding. macOS Finder shows 1,048,576-byte megabytes, some Windows dialogs show slightly different figures, and a form's uploader may measure in kibibytes or apply its own rounding before checking. When a file is sitting right at the edge of a limit — 103 KB against a 100 KB ceiling — the safest move is to retarget 10 percent lower rather than argue with the checker. The tool's output size display and your form's checker will occasionally disagree by a few kilobytes for exactly this reason, so leave yourself headroom on any near-miss.
Upload limits you will actually run into
Limits cluster into a handful of brackets, and knowing the bracket you are in tells you how aggressive the compression needs to be before you even start. Government forms are the strictest by a wide margin, mainly because their systems were built years ago on deliberately tiny budgets: Indian passport and PAN applications want photographs in the 20-50 KB range and signatures as low as 10 KB, the US DS-160 visa form caps photos at 240 KB while requiring at least 600x600 pixels, and countless state and municipal portals top out at 100 KB per document. Job applications and academic portals sit in the middle: resumes and CV portals commonly accept attachments up to 500 KB to 2 MB per file, while scholarship and admissions systems often cap individual document scans at 100-200 KB.
Email and messaging are looser but not free. Gmail and Outlook cap total message size at 25 MB (Gmail counts the base64-encoded version of attachments, which inflates binaries by about 37 percent, so the practical payload budget is closer to 18 MB), and many corporate mail filters quietly flag or quarantine anything heavier than 10 MB. Social platforms accept huge files but recompress them aggressively on their side — a 6 MB Instagram upload gets crushed to a few hundred KB by their pipeline whether you like it or not, so pre-shrinking the file yourself at least lets you control how it looks afterward.
The table below collects the brackets worth memorizing. None of these are official published standards for every case — portals update their forms without notice — but they are the numbers that come up again and again, and a file sitting inside its bracket almost always passes.
| Context | Typical limit | What that means in practice |
|---|---|---|
| Passport / PAN photo (IN) | 20-50 KB | Crop to form dimensions first; quality carries the reduction |
| Signature scans | 10-20 KB | Tight crop on white background fits with room to spare |
| US DS-160 visa photo | 240 KB max, 600x600 min | Lock dimensions, let quality alone bring bytes down |
| Government form documents | 100 KB | Shrink page width modestly + moderate quality drop |
| Resume / CV portals | 500 KB-2 MB | Usually fine as PDF; photos inside need pre-shrinking |
| Email attachment | 25 MB total message | Keep each image 150-300 KB to stay well clear |
| Social platform uploads | Accepted, then recompressed | Pre-shrink to ~500 KB to control the result |
What the JPEG quality number actually does to file size
JPEG quality is a 0-100 knob that controls how much visual detail the encoder is allowed to throw away, and its relationship to file size is steeply non-linear. The interesting region is between roughly 50 and 95. Below about 50, quality collapses fast — colors smear, blocky artifacts appear around edges — while the file barely shrinks further, so there is almost never a reason to go there. Above about 95, the opposite happens: file size climbs sharply while the improvement is invisible on any screen, because you are paying kilobytes to preserve detail no display will render.
Rough numbers from a typical 3 MB phone photo resized to 1200 pixels wide illustrate the curve. At quality 95 the file weighs around 700 KB; at 85 it drops to roughly 350 KB; at 75 it lands near 230 KB; at 60 it is about 150 KB with the first visible artifacts starting to show in flat gradients. The jump from 95 to 85 — a setting almost nobody can distinguish side by side — removes half the bytes. That is the entire trick behind efficient compression: park quality in the 75-85 band where each byte buys the most visible quality, and only push higher when the destination is print or a large display.
The exact numbers shift with image content — a photo of a forest compresses differently from a photo of a laptop on a white desk — which is why fixed presets mislead. Text-heavy screenshots behave differently again: sharp black-on-white edges survive quality 60 far better than a photographic gradient does, so a document scan at 60 can look perfectly clean while a family photo at 60 looks rough. This is also why the binary search on this page beats a fixed preset: it finds where your specific image, with its specific content, crosses your specific limit, instead of assuming an average.
Shrinking dimensions vs lowering quality: which saves more
The two levers reduce bytes in different ways, and choosing the right one depends entirely on where the image is going. Lowering quality keeps every pixel but stores them less precisely: the image occupies the same space on screen and prints at the same physical size, with only subtle softening if the quality is still reasonable. Shrinking dimensions removes pixels outright: a 3000-pixel image stepped down to 800 pixels looks identical on a phone screen at 800 pixels wide but has lost the detail a large monitor, a zoom gesture, or a printer would have used.
In pure bytes-per-visible-loss terms, quality is the cheaper lever in the 75-90 range and dimensions become the cheaper lever once quality has already been spent. A 3000-pixel photo squeezed to 100 KB without resizing has to drop to brutal quality levels — visible banding, waxy skin, ringing around text. The same file resized to 1000 pixels wide hits 100 KB at quality 80 and looks clean at anything up to fullscreen on a laptop. That is why the sensible default for 'small target, no dimension requirement' is to let both levers work: step dimensions down first to a size the destination can actually display, then let quality absorb the rest.
The exception is when the form checks pixels. DS-160-style requirements state both a kilobyte ceiling and a pixel floor precisely to prevent thumbnail-uploading, and in those cases dimensions are locked no matter what — quality is the only legal lever, and if the target is mathematically unreachable at that size, the right answer is a clearer message rather than a blurred file that fails inspection anyway. As a rule of thumb: form specifies pixels, lock pixels; form specifies only kilobytes, allow resizing and keep quality as high as the budget allows.
When converting PNG to JPG is the whole answer
PNG and JPEG solve different problems, and mismatching them is one of the most common sources of absurdly large files. PNG is a lossless format built for graphics: screenshots, logos, charts, anything with flat color areas and hard edges. Its compression finds repeated pixel patterns and stores them once, which is why a screenshot of a spreadsheet can shrink 10-to-1 as PNG. Photographs defeat it — every pixel in a photo is slightly different from its neighbors, there are no repeated rows to exploit, and a photo saved as PNG routinely weighs 5 to 15 times its JPEG equivalent with zero visible benefit.
The fix is simply re-encoding the photo as JPEG, which typically cuts 85 to 95 percent of the bytes before any quality reduction happens. A 6 MB PNG photograph becomes a 400 KB JPEG at quality 85 that is indistinguishable on screen. The places where PNG should stay PNG are exactly the places where the content is graphics: text screenshots, UI captures, diagrams, and anything that must not blur — JPEG's lossy encoding softens sharp edges, so converting a text screenshot to JPEG at low quality produces visible fuzz around characters that the PNG never had.
Transparency is the other boundary. PNG supports alpha channels — partially see-through pixels — and JPEG does not: converting a logo with a transparent background to JPEG fills the transparency with solid white (or black, depending on the encoder). If the destination needs transparency, PNG is mandatory and the size problem has to be solved with dimension reduction or a palette reduction instead. If the destination is a photo upload on a form that wants kilobytes, the transparency is irrelevant and JPEG conversion is free money.
WebP and AVIF: same kilobytes, better-looking result
JPEG has been the default photo format for thirty years, but two newer formats — WebP and AVIF — encode the same visual information with roughly 25 to 50 percent fewer bytes. At a 100 KB budget, a JPEG that looks merely acceptable can become a WebP that looks noticeably cleaner, because the codec has more efficient ways to represent colors and edges. Google introduced WebP in 2010 and it now has near-universal browser support, including every version of Chrome, Firefox, Safari since macOS Big Sur, and Edge. AVIF is newer, based on the AV1 video codec, and squeezes even harder — 30 to 60 percent smaller than JPEG at equivalent perceived quality — but encoding it is slower and some older systems still reject it at upload time.
The practical question for form uploads is whether the destination accepts the format. Most web browsers render WebP and AVIF perfectly; most government portals and HR systems do not: they were built years ago expecting JPEG or PNG, and an upload field may silently reject a .webp or .avif file even if the MIME type would technically pass a loose validator. Before switching formats, check whether the form specifies 'JPEG only' or 'JPG/PNG accepted' — that language appears in roughly half of strict upload portals. If the form accepts any image type, WebP is a straightforward win: the same 50 KB budget buys visibly more sharpness, particularly in facial detail and fabric texture, compared with a JPEG at the same file size.
One important difference is how the formats handle transparent areas. Both WebP and AVIF support alpha channels, just as PNG does, which means a logo or signature with a transparent background does not need to be converted to PNG just to preserve transparency. JPEG has no transparency support at all and fills any transparent region with a solid fill, usually white or black, which is why a signature scan on a transparent background always comes out as a white-background JPEG unless you specifically export it as WebP or PNG instead. For form uploads requiring a white background, that JPEG default is fine; for anything placed over a colored page, it is not.
Why the file is still over the limit — and how to fix it
You compressed to 100 KB, the tool says 98 KB, and the portal still rejects the upload with an error like 'file exceeds maximum allowed size' or HTTP 413 Request Entity Too Large. The most common cause is unit mismatch: the portal was programmed to check kibibytes (1 KiB = 1,024 bytes) while the tool you used reports in kilobytes rounded to 1,000 bytes. A file of exactly 100,000 bytes is 97.7 KiB, which passes. A file of exactly 100,500 bytes is 98.1 KiB, which also passes. But the 10 percent headroom rule becomes essential when the tool reports something like '99 KB' and the portal's limit is defined as 100 kibibytes — a number that is actually only 102,400 bytes. Retarget to 90 KB on the tool side and the mismatch disappears regardless of which system is doing the counting.
The second common cause is embedded format overhead that survives re-encoding. Some image editors insert proprietary metadata blocks — ICC color profiles, XMP records, Adobe-specific markers — that persist after quality reduction. A JPEG re-encoded at quality 60 can still weigh 15-20 KB more than expected if a bloated color profile rides along. The fix is to strip metadata explicitly: most command-line tools do this with a flag like --strip-all or --no-profile, and the browser-based tool on this page drops all such blocks during re-encoding since the output is reconstructed from decoded pixels rather than copied from the source. If a file consistently comes out heavier than the binary search predicts, metadata is almost certainly the explanation.
The third diagnostic step is checking actual pixel dimensions against what you assumed. A file labeled as a 1200-pixel JPEG sometimes turns out to be a 3600-pixel JPEG that your viewer scaled for display, and the 100 KB target becomes unreachable at those dimensions without severe quality degradation. Use the <a href='/image-size-in-kb-checker' className='underline'>image size checker</a> to confirm the pixel count before compressing. If dimensions are the hidden culprit, enabling resizing in the compressor and locking the width at something the destination will actually display — 800 pixels for a form thumbnail, 1200 pixels for a web page — immediately brings the file into range at a reasonable quality. A 3600-pixel image squeezed to 100 KB looks worse than an 800-pixel image at the same limit, because the byte budget is spread across nine times as many pixels.
DPI, pixel dimensions, and the myth of 'high-res' small files
DPI — dots per inch — is one of the most persistently misunderstood settings in image files, and it has almost no effect on file size in any format that matters for uploads. DPI is a metadata tag that tells a printer how many pixels to place per inch of paper; on a screen, the rendering engine ignores it entirely and maps each pixel one-to-one regardless of what the DPI field says. A 1,000-pixel-wide JPEG saved at 72 DPI and the exact same file saved at 300 DPI are byte-for-byte identical — the DPI tag is fewer than ten bytes of metadata in the EXIF block, not a part of the pixel data.
This matters in a specific failure mode that catches people regularly: an editor exports a photo at '300 DPI' believing this creates a higher-quality file, then wonders why the file size did not change. It did not change because DPI does not add or remove pixels — it only labels what printing resolution to use. What actually drives file size is pixel count times the spatial frequency of detail in those pixels, compressed by the codec at the chosen quality setting. A 4,000 × 3,000 pixel image is a 12-megapixel image whether the DPI tag says 72, 96, 300, or 1,200.
The related misconception is that changing DPI in a program like Photoshop or Preview will resize the image file for an upload. Some programs offer a 'change DPI without resampling' option that modifies only the metadata tag and does nothing to actual pixel counts or byte size. The correct workflow for reducing file size is to reduce actual pixels — change the width and height in pixels, not the DPI label — and then compress. If a form specifies '300 DPI minimum', it is almost always talking about print production requirements, not upload size, and a 600-pixel passport photo at 300 DPI prints correctly at 2×2 inches on paper while still being a small upload-friendly file. Related workflows for hitting specific pixel targets are covered on the <a href='/decrease-image-size-in-kb' className='underline'>decrease image size in KB</a> page.
A batch workflow that does not fall apart
Real jobs rarely involve one image. A visa application wants a photo, a signature, and a scan of a passport page, each with its own limit. A blog post involves eight screenshots that should all be under 150 KB. The failure mode in batch work is inconsistency: hand-tuning each file produces a set where one image is crisp and its neighbor is mush, and nobody remembers which file got which setting.
A workflow that holds up looks like this. First, sort by destination: everything going to the same form or page gets the same target. Second, fix the sources before compressing — crop to the required dimensions, straighten, and fix exposure, because a dark photo re-encode amplifies noise and costs bytes for nothing. Third, run each group through with its target and check the two or three files that matter most at full size rather than every file at thumbnail size. Fourth, name outputs by their target — passport-photo-40kb.jpg, signature-15kb.jpg — so three weeks later, when the portal asks you to re-upload, you know exactly which file fits without recompressing anything.
Since the tool runs entirely in the browser with no upload, batching is just repeating the drop-compress-download cycle per file — there is no server queue to wait on, and with a binary search converging in roughly seven re-encodes, each file takes a couple of seconds. For a folder of twenty screenshots, that is under a minute end to end, and the one-pass-from-original rule from the top of this page is what keeps file nineteen looking as good as file one: every image in the batch gets compressed exactly once, from its own clean source, at the same target.