How an image is made to hit an exact KB size
What sets a JPEG's size, how the tool trades quality against pixels to land under a limit, the two meanings of a kilobyte, and what DPI really changes.
Last reviewed · 2,338 words
In short
- If the form states a pixel size, type it in as pixels or centimetres. The tool then moves only the JPEG quality and never changes the pixels.
- When the tool reduces, a 50 KB limit is met at 50,000 bytes or less. Windows shows that file as 48.8 KB, which is the file passing under both readings of a kilobyte, not falling short.
- Set the DPI to the number the form asks for. It is a field in the file header and adds no detail; only a larger size in pixels or centimetres adds pixels.
- To turn centimetres into pixels, divide by 2.54 and multiply by the DPI. 5 cm at 200 DPI is 394 px.
- Choose Crop to fill when a face must fill a fixed frame, and Fit whole photo when nothing may be cut off.
An upload form wants a photo under 50 KB, or between 20 and 50 KB, and the one on your phone weighs several megabytes. The tool above closes that gap without sending the photo anywhere. This page explains how it chooses the pixels, the quality and the exact byte count.
What sets the size of a JPEG
Three things decide how many bytes a JPEG takes.
Pixels. Bytes scale roughly with area. Halve both sides and you keep a quarter of the pixels and, roughly, a quarter of the bytes.
Detail. Grain, hair, leaves and the noise of a dim room all cost bytes; a plain wall costs very little. Two photos of the same pixel size can come out far apart in KB for this reason alone. The 20 KB guide covers photographing for a small file.
Quality. The JPEG quality setting decides how much of that detail the encoder keeps. Browsers take it as a number between 0 and 1 when a canvas is encoded; the tool shows it as a percentage.
With a fixed pixel size, quality is the only lever; when the pixels are free to change, the tool uses both.
Where the work is done
Everything described on this page runs inside your browser tab. The page reads the file from your own device, draws it onto a canvas and has the browser encode that canvas as a JPEG. There is no upload endpoint for the photo to reach, and once the page has loaded it keeps working with the connection switched off.
Re-encoding from a canvas also drops everything the original carried besides the picture. A canvas holds only pixels, so the download has no EXIF block: no GPS location, no camera model. The phone's rotation tag is applied before drawing, so the photo comes out upright, and a transparent PNG is laid on white first, because JPEG has no transparency and empty pixels would otherwise turn black.
The input can be a JPG, PNG or WebP of up to 30 MB, or anything else the browser can open. An iPhone HEIC opens only in browsers that support it; elsewhere, share the photo from the phone as a JPEG. The longest side is capped at 4,000 px as the file is decoded.
How the tool searches for the right quality
The tool tries JPEG quality settings between 5% and 95% and keeps the highest one whose file is at or under the maximum. The byte count it reports is the length of the file you download, not an estimate.
When the photo is far too big for the target, the tool first guesses a pixel size from roughly 0.1 byte per pixel: pixels ≈ maximum bytes ÷ 0.1. A 20 KB maximum is 20,000 bytes, so the guess is about 2,00,000 pixels, or 516 × 387 for a 4:3 photo. Starting near the answer spares a 12-megapixel photo from being encoded again and again at a size that could never fit.
In the tests below the whole search took 0.5 to 2.3 seconds on a desktop.
One test photo, eight targets
We made a 4,032 × 3,024 test photo with strong grain, 50,29,726 bytes (4.80 MB), and ran it through this page with the shape kept. Because of the 4,000 px decode cap, the working image was 4,000 × 3,000.
| Target | Output bytes | Pixels | JPEG quality | Time (desktop) |
|---|---|---|---|---|
| 10 KB | 9,855 | 329 × 247 | 45% | 0.6 s |
| 20 KB | 19,902 | 516 × 387 | 53% | 0.5 s |
| 30 KB | 29,732 | 632 × 474 | 63% | 0.5 s |
| 50 KB | 49,823 | 816 × 612 | 72% | 0.5 s |
| 100 KB | 98,439 | 1,155 × 866 | 75% | 0.7 s |
| 200 KB | 1,97,314 | 1,633 × 1,225 | 76% | 0.8 s |
| 500 KB | 4,94,413 | 2,582 × 1,936 | 71% | 1.2 s |
| 1,000 KB | 9,87,489 | 4,000 × 3,000 | 54% | 2.3 s |
Every file sits between 98.4% and 99.6% of its maximum, so little of the allowance is wasted. From 20 KB to 500 KB the pixel counts are within 0.2% of the first guess: the guess held and the quality search did the rest, which is why quality wanders between 53% and 76%. At 1,000 KB no reduction was needed.
The grain makes this photo harder to compress than most real ones, so an ordinary photo usually comes out larger in pixels at the same KB.
Why the pixels shrink before quality drops below 40%
Below about 40% JPEG quality, faces turn blocky, and a smaller picture at good quality looks better than a large one at very low quality. So when the photo is still over the maximum at 40%, the tool reduces the pixel size instead.
It shrinks by roughly the square root of the overshoot, because bytes scale with area. A file 1.44 times too big has each side cut to a little under 83% (1 ÷ √1.44 ≈ 0.83, less a small safety margin), and the search runs again. With the shape kept, only at a tiny size does quality go below 40%. The 10 KB row is where this happened: the first guess of about 1,00,000 pixels was too big even at 40%, so the tool shrank again and settled at 329 × 247 and 45%.
Large reductions are drawn in halving steps rather than one jump; 4,000 px down to 516 is almost three halvings. In a single step, fine lines such as a signature stroke can alias into broken, jagged lines.
Meeting a limit under both readings of KB
Software does not agree on the size of a kilobyte: some counts use 1,000 bytes and some 1,024, and no upload notice we have read says which it means. Which devices and checkers use which is set out in the MB to KB converter guide.
The tool does not guess: a maximum of X KB becomes at most X × 1,000 bytes, and a minimum of X KB becomes at least X × 1,024 bytes. Each edge takes the stricter reading, so the byte count sits inside the limit whichever way the form counts.
| You ask for | Bytes in the file | Windows shows |
|---|---|---|
| Maximum 20 KB | at most 20,000 | at most 19.5 KB |
| Maximum 50 KB | at most 50,000 | at most 48.8 KB |
| Range 10–20 KB | 10,240 to 20,000 | 10.0 to 19.5 KB |
| Exactly 50 KB | exactly 51,200 | 50.0 KB |
A 48.8 KB result against a 50 KB limit is the margin that keeps the file inside the limit under the 1,000-byte reading. The last row is different: an exact size is a size to reach, not a limit, so it lands on exactly 50 KB as Windows counts, which is 51.2 kB to a phone that counts 1,000 bytes.
A range can be too narrow to satisfy both rules at once. 49.5–50 KB would need at least 50,688 bytes and at most 50,000, so the tool refuses it with a message rather than meet one reading and break the other.
When the file has to get bigger
Under the size field sit two choices. At most this size, the default, treats the number as a ceiling: a photo over it is reduced as above, and a photo already under it is saved again at the best quality that still fits, never made bigger. Exactly this size fills a smaller photo up to the number, for forms that set a minimum.
Choosing exactly aims at X × 1,024 bytes. The photo is saved at 95% quality at its own pixel size, or brought down to just under the target first if even that is too big, and the shortfall is made up with bytes that image viewers skip over. Added kilobytes cannot add detail; the padding adds nothing to the picture. Where those bytes sit in the file, why the JPEG standard allows them and why forms set minimums at all is the subject of the increase guide.
Keep exactly for forms that state only a minimum. A file of exactly X × 1,024 bytes is over the 1,000-byte reading of the same number, so a form that states X as its maximum should be met with at most, which is why at most is the default.
For a range, choose at most and type the minimum as well. Whether it comes from a preset or is typed, the tool then finds the best quality under the maximum. If that is still under the minimum, common for small plain pictures, it pads to the middle of the byte range, the point furthest from both edges.
DPI, centimetres and pixels
DPI is a label, not a quality setting. It is written into the JFIF header with the units set to dots per inch, and not one pixel changes. The file this tool makes carries no other resolution field, so a form that checks DPI can only read that one; some forms, such as UTIITSL's online PAN form, do not check DPI at all. The page offers 72, 96, 150, 200, 300 and 600.
DPI matters in one place: centimetres. A printed size has no pixel count until you say how many dots go in an inch, so a size typed in centimetres is converted with the DPI you picked: pixels = cm ÷ 2.54 × DPI, rounded. The UPPSC photo, 5 cm wide and 6 cm high:
| DPI | 5 cm wide | 6 cm high |
|---|---|---|
| 96 | 189 px | 227 px |
| 150 | 295 px | 354 px |
| 200 | 394 px | 472 px |
| 300 | 591 px | 709 px |
| 600 | 1,181 px | 1,417 px |
The 200 DPI row is the UPPSC photo preset. For a size in centimetres, a higher DPI puts more pixels under the same KB limit, and so usually a lower quality; use the figure the form states.
The formula also runs backwards, which is how a program decides how large a file will print: cm = pixels ÷ DPI × 2.54. The preset's 394 px labelled 200 DPI reads as 5.00 cm; the same pixels labelled 300 DPI would read as 3.34 cm. A form that states centimetres and a DPI is satisfied only when the two agree.
Fixed size or kept shape, cropped or fitted
Keep shape leaves the proportions alone and lets the tool choose the pixel size, as in the test table. It usually gives the best-looking result for a given limit, because pixels can be traded for quality.
Pixels or Centimetres fixes the frame. The pixel size is never changed to hit the target; quality alone moves, as far down as it must. A small frame with a generous limit leaves much of the allowance unused: with our portrait test photo, the UPPSC photo preset, 394 × 472 px, came to 17,355 bytes, about 35% of the 49,990 allowed.
When the frame's shape differs from the photo's, there are two ways to fill it.
Crop to fill
The frame stays fixed and you drag and zoom the photo under it; the arrow keys work too. Whatever falls outside is cut off. This suits a face that must fill the frame.
Fit whole photo
The whole photo sits inside the frame and the leftover space becomes white margins. Nothing is cut. The signature page always places a signature this way, and also trims and whitens the paper.
The form presets on this page
A preset fills in whatever the specification fixes. The ones here are photos and documents; signature presets are on the signature page. Sizes are width × height, and the DPI is the one the preset writes into the file.
| Preset | Size | DPI | File size | Bytes aimed for |
|---|---|---|---|---|
| IBPS/SBI photo | 200 × 230 px | 200 | 20–50 KB | 20,480 to 50,000 |
| IBPS/SBI left thumb | 240 × 240 px | 200 | 20–50 KB | 20,480 to 50,000 |
| IBPS/SBI declaration | 800 × 400 px | 200 | 50–100 KB | 51,200 to 1,00,000 |
| UPSC photo | shape kept | 200 | 20–200 KB | 20,480 to 2,00,000 |
| UPPSC photo | 5 × 6 cm (394 × 472 px) | 200 | under 50 KB | up to 49,990 |
| PAN Protean photo | 2.5 × 3.5 cm (197 × 276 px) | 200 | max 20 KB | up to 20,000 |
| PAN UTIITSL photo | 213 × 213 px | 300 | under 30 KB | up to 30,000 |
IBPS and SBI call their photo and signature pixel sizes "preferred". With a preset, the page always works to the stated limits: best quality under the maximum, padded to the middle if that falls under the minimum. On our test images the left thumb and the declaration both came out short of their minimums and were padded to 35,240 bytes, halfway between 20,480 and 50,000, and 75,600 bytes, halfway between 51,200 and 1,00,000. The UPSC photo went the other way: best quality under 2,00,000 bytes, at 1,225 × 1,633 px and 1,88,953 bytes.
The presets follow the authorities' published figures as read on 24 September 2026; check the notice you are applying under. The UTIITSL pixel size and DPI appear only on third-party sites, and the tool labels them so; UTIITSL's own form checks only the file type and size. The PAN page covers both agencies.
What this tool assumes
- The photo never leaves your device. There is no upload endpoint, and once the page has loaded it works offline.
- Input is JPG, PNG or WebP up to 30 MB, with HEIC only where the browser supports it. Photos are turned upright, and the longest side is capped at 4,000 px.
- A typed number is a ceiling unless you choose "Exactly this size": at most
X × 1,000bytes by default, or exactlyX × 1,024bytes when chosen. A typed minimum makes it a range. A range too narrow to meet under both KB readings, such as 49.5–50 KB, is refused with a message rather than met under one reading only. - Output is always a JPEG with a JFIF header, named after the original with a suffix, such as
IMG_1234-20kb.jpg. - The output carries no EXIF data, so no GPS location or camera model, because a canvas re-encode does not copy it.
- Transparent PNGs are drawn onto white first, since JPEG has no transparency.
- Meeting a form's stated rules is not the same as acceptance; the form's own checks still decide.
Sources
- ITU-T Recommendation T.81 (ISO/IEC 10918-1), the JPEG standard
- JPEG File Interchange Format (JFIF) version 1.02
- MDN Web Docs — HTMLCanvasElement.toBlob() and its quality argument
- SBI PO 2026 detailed advertisement (photo, thumb and declaration specifications)
- UPSC online instructions for the photo and signature
- UPPSC One Time Registration — photo and signature upload guidelines
- Protean PAN — DSC instructions (photo and signature specifications)
- UTIITSL online PAN form — upload validation script