MB to KB Converter for Photos

Your phone lists a photo at one size, your laptop at a slightly smaller one, and the upload form asks for neither: it wants the photo in KB, under a limit far below both. Before you can fix that you need two numbers: the photo's size in the unit the form uses, and how far it has to shrink. The tool above shows the first and does the second in your browser; this page explains the units behind both.

From bytes to kilobytes to megabytes

A file's size is a count of bytes. KB and MB are shorter ways of writing that count. In the count Windows and most upload forms use, every step up the ladder divides by 1,024:

• KB = bytes ÷ 1,024
• MB = KB ÷ 1,024 = bytes ÷ 10,48,576

The 1,024 is 2¹⁰, the power of two closest to a thousand, borrowed as the "kilo" of computing. The other count, used by Android and macOS, divides by 1,000 at each step.

The byte count is exact; a figure in KB or MB is usually a rounded description of it. The tool shows all three as soon as you choose a photo. Our 4,032 × 3,024 test photo read as 4.80 MB, which is 4,912 KB, which is 50,29,726 bytes.

Two kinds of kilobyte

Everywhere else in measurement, kilo means exactly a thousand: a kilometre is 1,000 metres. Using it for 1,024 opens a gap that compounds at every step. A binary kilobyte is 2.4% larger than a decimal one, a binary megabyte 4.9% larger, and a binary gigabyte 7.4% larger.

Separate names exist for the binary units. The International Electrotechnical Commission approved them in December 1998, and NIST sets them out: a kibibyte (KiB) is 1,024 bytes and a mebibyte (MiB) is 10,48,576 bytes, while kilo, as an SI prefix, strictly means 1,000. None of the exam and PAN upload rules we checked uses the new names; they all write KB, kB or kb.

The forms we checked never say which kind of kilobyte they mean. Most form validators count in 1,024s: a common check reads file.size <= 50 * 1024. UTIITSL's online PAN form is one real example; its script divides the file size by 1,024 before comparing it with the 30 KB photo limit. The PAN photo page covers that form in full.

Why a phone and a Windows laptop disagree

Copy a photo from an Android phone to a Windows laptop and its size seems to change. Nothing in the file changed. The two systems divide the same byte count by different numbers: Android has shown file sizes in decimal units since version 8.0, and macOS does the same, while Windows divides by 1,024 and still labels the result KB and MB. A Mac and an Android phone therefore agree with each other.

In the same unit, the phone's number is the bigger one: about 2.4% bigger in KB (a factor of 1.024) and about 4.9% bigger in MB (a factor of 1.048576).

The form sees neither figure. The browser hands it the exact byte count, and the form's own code does the dividing, which is why the byte count is the number to trust when two screens disagree.

MB to KB for a few photo sizes

Each size, converted both ways:

For any other size, multiply the MB by 1,024 for KB and by 10,48,576 for bytes, or by 1,000 and 10,00,000 for the decimal reading.

A size read off an Android phone is in decimal units. To put it the Windows way, divide an MB figure by 1.048576 (or a KB figure by 1.024): a photo the phone lists as 5.03 MB is 4.80 MB, or 4,912 KB, on a Windows laptop. When two figures disagree, go by the bytes: that is the one number every device and every form's code agree on. For data units with no file involved, the unit converter does the arithmetic on its own.

Reading a limit written in KB or MB

A form's limit has the same two readings as a file's size. The tool settles it by meeting the stricter reading at each edge, as the Image Resizer in KB guide explains, so a maximum is met in thousands of bytes. That matters most when the limit is large:

For a limit given in MB, type it as thousands of KB: 1000 for 1 MB, 2000 for 2 MB. The result then sits at or under the megabyte whichever way the form counts it. Typing 1024 for 1 MB would allow up to 10,24,000 bytes, which is under a binary megabyte of 10,48,576 but 24,000 bytes over a decimal one.

So a 100 KB target that comes back as 96.1 KB in Windows terms, as our test photo did, has not fallen short; it has passed under both readings. Limits of a few tens of KB, the kind signatures and ID photos get, have traps of their own, covered in the 20 KB resizer guide.

What a phone photo weighs, and why

A photo's size is roughly its pixel count times what each pixel costs once compressed:

bytes ≈ pixels × bytes per pixel

The camera fixes the pixels. Our test photo is 4,032 × 3,024, which is 1,21,92,768 pixels, or 12.2 megapixels. Stored plainly, with one byte each for red, green and blue, that would be 3,65,78,304 bytes, about 34.9 MB. As a JPEG it was 4.80 MB, about 7.3 times smaller, at roughly 0.41 byte a pixel.

The bytes per pixel is where photos differ. JPEG spends bytes on detail: grain, hair, leaves, printed text, the noise of a dim room. A plain wall or a clear sky costs very little. Two photos with the same pixel count, from the same phone, can land far apart in MB purely because of what is in them.

We gave the test photo heavy grain deliberately, so treat it as a hard case: an ordinary photo will usually keep more pixels at the same KB than the figures below.

How far a photo has to shrink

Getting that test photo under a form's limit was not a trim. At 100 KB the file had to become 51 times smaller. The table splits each result from this tool's engine, with the shape kept, into its two parts: fewer pixels, and fewer bytes for each pixel that is left.

The original ran at 0.41 byte a pixel. From 20 KB to 500 KB every result settled near 0.1, so the pixel count did most of the adjusting. At 100 KB the pixels fell 12.2 times, each side about 3.5 times shorter, to 1,155 × 866, while the bytes per pixel fell 4.2 times, at 75% JPEG quality; 12.2 × 4.2 brings you back to 51.

From 20 KB to 500 KB, every 100 KB of target bought about one megapixel, so the largest limit a form allows is the one to choose. At 1,000 KB, a decimal megabyte, the engine's whole 4,000 × 3,000 working copy fitted at 54% quality, and no further pixels had to go.

What the page does with your target

Pick 20, 50, 100, 200 or 500 KB, or type your own maximum, and the tool compresses a copy of the photo in the browser tab. It gives up pixels rather than let the JPEG quality sink below 40%, so every result in the table above kept a quality of 53% or more.

This page keeps the photo's shape and chooses the pixel size for you; it has no pixel, centimetre or DPI fields. A form that fixes any of those needs the general resizer, which has all three.

What you save keeps the original's name with the target added, as in IMG_1234-20kb.jpg. To make a small file bigger instead, the increase page pads it to an exact size without touching the picture.

Photos only, not PDFs

The tool reads photos, JPG, PNG and WebP up to 30 MB, and always saves a JPEG. It cannot open or shrink a PDF, which is a different kind of file with its own ways of storing pages and text.

Some forms ask for both, with limits in different units. Protean's e-Sign upload guide for PAN asks for the photo and signature as .jpg files of at most 50 kB each and the supporting documents as a PDF of no more than 300 kB, while UTIITSL's online PAN form takes supporting documents as PDFs of up to 5 MB. If the form asks for a PDF, use a PDF tool; renaming a JPEG to .pdf does not make it one.

What this tool assumes

• Sizes are displayed the Windows way, 1 KB = 1,024 bytes and 1 MB = 1,024 KB, with the full byte count beside them.
• A typed maximum is met at X × 1,000 bytes or fewer, and an optional minimum at X × 1,024 bytes or more, so either count of KB is satisfied.
• The quick picks are 20, 50, 100, 200 and 500 KB; any other maximum can be typed, including thousands of KB for a limit in MB.
• The photo is compressed on your own device and never sent to a server; the Image Resizer in KB guide describes the engine behind it. The file you get back is a JPEG with no EXIF data, so it holds no location or camera model.
• The measurements here come from a test photo we made to be hard to compress, and your own photo will usually do better. Hitting a form's stated limit does not by itself decide whether the form takes the file.