How to make a picture smaller in KB, on any device

Somewhere between the camera and the upload button, a picture turns into a problem. The form wants 200 KB. Your phone says the file is 4.2 MB, which is roughly twenty times too much, and the only thing in front of you is a photo app offering filters, a crop handle and no field anywhere that says “size”.

The gap is not really technical. It is that “make it smaller” describes two entirely different operations, and almost everybody reaches for the wrong one first.

Why kilobytes are still the unit

Nobody measures storage in kilobytes any more. A phone with 256 GB of space does not care whether a photo is 200 KB or 4 MB, and neither do you, most of the time.

Kilobytes survive in exactly one place: forms that accept uploads. A visa portal, a university application, an exam registration, a bank’s identity check, an insurance claim. The limit is not there to save disc space — it is protecting a database column, a mail relay, or a queue of documents that a human will eventually open one at a time. Whoever wrote the number picked something comfortable for their system and moved on, which is why the limits are so varied and so rarely explained.

One quirk is worth knowing before you start. “KB” is ambiguous: it can mean 1,000 bytes or 1,024, and a form that advertises a 200 KB limit may be comparing your file against 200,000 bytes or against 204,800. You cannot tell which from the outside, and the error message will not say. Aim a little under the number rather than exactly at it.

Two knobs, and they are not the same knob

Every picture has two independent properties that affect its size.

Dimensions are how many pixels there are. A recent phone photograph is commonly something like 4,032 × 3,024 — about 12 million pixels, most of which you will never see, because whatever displays the picture will shrink it to fit.

Quality is how hard each surviving pixel is squeezed. In JPEG this is a number from 0 to 100, and it controls how much detail the encoder is permitted to discard.

These are separate. You can have a huge picture at low quality or a tiny one at maximum quality, and people routinely confuse the two — reaching for a quality slider, dragging it down until the picture looks bruised, and still not hitting the target, because they never touched the pixel count.

The reason dimensions usually win is arithmetic. Halving the width and the height leaves you with a quarter of the pixels, because you halved both axes. A 4,032 × 3,024 photo becomes 2,016 × 1,512 — still three megapixels, still sharper than most screens will show it, and three quarters of the data is gone before the compressor has done anything at all.

That is the best ratio of bytes saved to damage done that you will find anywhere, with one important qualifier: it only holds while you are above the resolution the picture actually needs. Surplus pixels are free to throw away. Necessary ones are not, and once you reach the size the picture has to be, resizing stops being cheap and quality becomes the better lever.

Deciding how many pixels the picture needs

This is the question that sets the target, and it has nothing to do with file size.

If the picture will be looked at on a screen, 1,600 to 2,000 pixels on the long edge is generous — that is larger than most people’s browser windows, and it survives a bit of zooming. If it is going in a document or an email for someone to glance at, 1,200 is plenty. If it is a profile picture or a thumbnail, 400 to 600. If a form specifies dimensions, use theirs and stop thinking about it.

If it is going to be printed, the calculation is different: printers want roughly 300 pixels per inch of paper, so a photograph printed 6 inches wide needs about 1,800 pixels across. This is the one case where resizing down is genuinely destructive and you should reach for quality instead.

For the common case — something that will only ever be looked at on a screen — resizing to 1,600 pixels on the long edge and then compressing usually gets a phone photo comfortably under a few hundred kilobytes without anything visible changing.

The second knob, and where it starts to hurt

JPEG works by chopping the image into 8 × 8 blocks, describing each block as a set of frequency components, and then rounding those components off. The quality number controls how coarsely it rounds. Higher quality, finer rounding, more bytes.

The encoder documentation is unusually candid about the useful range. The reference JPEG encoder defaults to quality 75 and states that the setting “should generally be between 50 and 95 … for photographic images”, noting that above about 95 the file grows dramatically for a gain that is “rarely perceivable by human vision”.

In practice, on the pictures people actually need to shrink, the trouble starts higher than the bottom of that band. Below roughly 70 the damage becomes findable if you look: skin tones go slightly blotchy, smooth gradients — skies, studio backdrops, out-of-focus backgrounds — break into visible steps, and hard edges pick up a faint halo. Faces are the most sensitive subject there is, because you have spent your whole life looking at them. Treat 70 as a rule of thumb rather than a rule; a photograph of a textured wall will survive far lower, and a portrait against a plain background will not.

There is a related detail that explains why colour usually breaks before brightness does. Most JPEG encoders store colour at half the resolution of luminance by default — 4:2:0 chroma subsampling — on the reasonable grounds that human vision is far more sensitive to changes in brightness than in hue. It is why saturated reds smear at the edges long before anything else looks wrong.

Sometimes the format is the entire fix

The same picture, with the same dimensions and the same visual quality, is a different number of bytes in different formats. Occasionally that difference is the whole problem.

Two cases come up constantly. The first is HEIC. Recent iPhones capture in HEIF by default when the camera format is set to “High Efficiency” rather than “Most Compatible”, and Apple’s own description is that the format offers “better compression than JPEG … while preserving the same visual quality”. Efficient, but a large number of upload forms will not accept it at all, so the conversion is forced on you anyway.

The second is a photograph saved as PNG — usually because it passed through a screenshot, a messaging app or a design tool at some point. PNG is lossless, which means it stores a photograph honestly and enormously. Converting it to JPEG can cut it by an order of magnitude with no visible change, and no resizing required.

WebP sits between the two: Google’s own comparison puts it 25–34% below JPEG at matched SSIM. That is a real saving if the destination accepts it. Many official forms accept JPG and PNG only, and reject anything else without explanation, so check before you commit.

Screenshots and text behave backwards

Everything above assumes a photograph. Screenshots, scanned documents, diagrams and anything containing text follow the opposite rules, and the mistake is common enough to be worth stating plainly.

Lossy compression is built for the smooth tonal variation of photographs. Text is the opposite: hard black-on-white edges, exactly the thing that produces the worst artefacts. Mozilla’s format guidance is direct about it — you should prefer a lossless format for screenshots, “particularly important if there’s any text in your screenshot, as text easily becomes fuzzy and unclear under lossy compression”.

So for a screenshot, the quality knob is the wrong one to reach for; it will make the text look photocopied before it saves you much. The moves that work instead are cropping away everything that is not the point, keeping the format lossless, and reducing dimensions only as far as the smallest text stays comfortably readable. Flat interface screenshots compress extremely well losslessly, because large areas of identical colour are precisely what lossless compression is good at.

What your device can and cannot do

Built-in tools vary more than you would expect, and the menus get renamed often enough that any click-by-click guide is wrong within a year. It is more useful to know what capability to look for.

On iPhone, the Photos app can crop, rotate and adjust, but it has no resize control and no export-quality setting — cropping is the only size lever it gives you directly. The capability does exist on the device, in the Shortcuts app, whose transform actions Apple describes as ones that “edit content (such as cropping an image) or convert content to a different format (such as changing a PNG to a JPEG)”. Building a shortcut once gives you a permanent resize option in the share sheet.

On Android, it depends on the gallery. The Google Photos editor offers markup, filters, crop, adjustments and its retouching tools, and nothing in it that sets pixel dimensions or file size. (Its Storage saver backup setting does resize — anything over 16 MP — but that governs what Google keeps, not the copy you hand to a form.) Samsung’s Gallery does have a resize option, reached through the editor’s overflow menu, which scales the picture down by a percentage. If your gallery has no such option, cropping is again the lever you have.

On Windows, the Photos app’s editor covers crop, adjustment, filters, markup, generative erase and background, none of which set pixel dimensions. The resize route Microsoft actually documents is PowerToys Image Resizer: install PowerToys, then right-click one or more image files in File Explorer and choose “Resize with ImageResizer”, which takes sizes in pixels, per cent, inches or centimetres.

On macOS, Preview handles both knobs without any extra software: Tools > Adjust Size for dimensions, with scale-proportionally and resampling options, and the export dialogue for format and quality.

One thing that is not a technique, despite being widely used as one: emailing a picture to yourself to shrink it. Some mail clients do downscale attached images, but it is an offer rather than a rule — Outlook proposes compressing or resizing images over 1 MB as you attach them, and classic Outlook has a “Resize large images when I send this message” option. What you cannot rely on is any particular client shrinking a picture to any particular size. If email is the actual destination, the limits and the encoding overhead are worth understanding directly.

Always work from the original

Every lossy save throws information away permanently, and the losses stack. Open a compressed JPEG, change something trivial, save it again, and the encoder quantises an image that has already been quantised — rounding numbers that were themselves the result of rounding. Resizing between saves makes it worse, because the 8 × 8 block grid no longer lines up with where the previous artefacts were, so the new encode spends bits faithfully reproducing the old encode’s mistakes.

The practical consequence: if you compressed a picture to 500 KB last week and now need 100 KB, go back to the original and compress once to 100 KB. Do not compress the 500 KB copy again. The one-step result is meaningfully better, and it costs nothing extra to do it that way.

The floor, honestly

At some point the two knobs run out. If you have already removed the surplus pixels and quality is down where the damage shows, the only remaining move is fewer pixels still — and a picture that has to remain legible or recognisable has a size below which it simply cannot go.

A passport photograph at 10 KB is possible. A page of dense text as a photograph at 10 KB is not, in any way that leaves the words readable. If a form demands a number your content cannot reach, the answer is usually that the content is wrong for the form — the text should be a PDF, the diagram should be a screenshot rather than a photograph of a screen, the document should be scanned in greyscale rather than photographed in colour.

If you would rather not think about any of this, working backwards from the number is the more direct route: name the size you need and let the encoder search for the highest quality that fits, as the 100 KB compressor does. It runs a real encode at each step rather than estimating, and it reduces resolution only when no quality setting can get there — which is the same order of operations described above, applied automatically.

Everything runs in your browser tab. That matters more than usual for this particular category of file, because the pictures people most often need to shrink to an exact kilobyte figure are identity documents, bank statements and photographs of their own faces.