Why Your Resized Photo Still Gets Rejected

Resizing an image is the easy part. The frustrating part is a portal that rejects the result with something unhelpful like "Invalid file. Please upload a valid photograph." You check the file. It's 48 KB against a 50 KB limit. It's 200×230 pixels, exactly as specified. And it still won't go through.

Almost always, the upload form is checking something it never told you about. Below are the seven causes we see most often, ordered roughly by how frequently they're the culprit, with a way to confirm each one.

1. The extension says .jpg but the file isn't JPEG

This is the big one. Renaming photo.png to photo.jpg changes nothing about the bytes inside it. Upload forms don't trust extensions — they read the first few bytes of the file, called the magic number, to identify the real format. A JPEG starts with FF D8 FF. A PNG starts with 89 50 4E 47. If the portal expects the first and finds the second, it rejects the file no matter what the name says.

This trips people up constantly because Windows and macOS both hide extensions by default, and because a lot of tools "convert" by renaming. Screenshots are the classic case: press Print Screen or use the Snipping Tool and you get a PNG, even if you save it with a .jpg name.

How to confirm: open the file in any image viewer and check the reported format, or look at Properties → Details on Windows, or Get Info on macOS. If it says PNG anywhere, that's your answer.

The fix: genuinely re-encode the image rather than renaming it. In our resizer, choose JPEG (.jpg) in the format dropdown before you download — the image is re-encoded through the canvas, so the output really is a JPEG at the byte level.

2. A transparent background became black

PNG supports transparency. JPEG does not. When a PNG with a transparent background is converted to JPEG, every transparent pixel has to become some solid color — and the default in many tools is black, because a transparent pixel's underlying RGB value is often 0,0,0.

The result is a passport photo with a black background, which fails the "plain light background" requirement even though the dimensions and file size are perfect. Sometimes it fails an automated face-detection check too, because the contrast confuses the detector.

How to confirm: look at the downloaded JPEG, not the preview in the tool you used. Many editors show transparency as a white-and-gray checkerboard, so a black background only appears after conversion.

The fix: put a white background behind the subject before converting. Our background remover outputs a transparent PNG; if the form wants JPEG on white, flatten it onto white first rather than converting the transparent PNG directly.

3. There is a minimum size as well as a maximum

Everyone reads the maximum. The minimum is what catches people. A form that says "between 20 KB and 50 KB" will reject a beautifully optimized 12 KB file, and the error message usually just repeats the range without saying which end you missed.

The logic behind it is reasonable: a file that's too small is probably too low-resolution or too heavily compressed to be legible, and these photos end up on printed ID cards. Signature uploads very often specify a floor — the IBPS signature range is 1 KB to 15 KB, for instance.

How to confirm: re-read the instructions for the words "minimum", "at least", or a range written with a hyphen. Then check your file's actual size.

The fix: if you're under the floor, you need a bigger file. Increase the pixel dimensions toward the top of the allowed range, or set a target size closer to the maximum instead of the minimum. Aim for the middle of a range, not either edge.

4. The dimensions are right but the aspect ratio isn't

Some portals check width and height independently; others check the ratio between them. If you resized without keeping proportions locked, your photo may be the correct number of pixels wide and tall while the face inside it is visibly stretched — and an automated face check can fail on a distorted face even when the numbers pass.

There's a related trap in how you get to the target size. If your source photo is 4:3 and the form wants 7:9, resizing alone cannot give you both the right dimensions and an undistorted face. You have to crop to the target ratio first, then resize the cropped result.

How to confirm: divide width by height for both your file and the requirement. If the two numbers differ by more than a percent or so, you stretched it.

The fix: crop to the ratio, then resize. Use the crop tool with a fixed ratio — 7:9 for the 35×45 mm photo used by the UK, Schengen countries and most ICAO-aligned standards, or 1:1 for a US passport — and then set the pixel dimensions.

5. It's a progressive JPEG and the portal wants baseline

JPEG has two storage layouts. Baseline JPEGs decode top to bottom in one pass. Progressive JPEGs store several increasingly detailed passes, so the image appears blurry-then-sharp while loading — which is why they're popular on the web.

Older government and exam systems sometimes use image libraries that only handle baseline, and a progressive file either fails validation or uploads and then displays as a gray box. This is a genuinely obscure cause, but when it bites, nothing about the file size or dimensions gives you a clue.

How to confirm: hard to check without a tool that reports the JPEG scan structure. Treat this as the hypothesis of last resort — after ruling out the causes above.

The fix: re-encode through a browser canvas, which produces baseline JPEG. Any download from our resizer with JPEG selected is baseline, so simply running the file through it resolves this.

6. EXIF orientation makes it look rotated

Phone cameras record the photo in the sensor's native orientation and add an EXIF Orientation tag saying "rotate this 90° when displaying." Your phone's gallery, your laptop's preview and most modern browsers all honour that tag, so the photo looks upright everywhere you check it.

Then you upload it and it appears sideways, because the portal's image processing ignored the tag and used the raw pixel data. You are looking at a rotated photo that "was fine a second ago", which is maddening.

How to confirm: if a photo straight off a phone looks correct locally but rotated after upload, this is almost certainly why. Portrait photos taken in landscape grip are the usual victims.

The fix: rotate the image explicitly so the pixels themselves are upright, then re-save. Cropping through our crop tool also resolves it, because the output is written fresh from the canvas rather than carrying the original tag forward.

7. KB, KiB, and the limit you didn't quite meet

There are two definitions of a kilobyte in circulation. Decimal KB is 1,000 bytes. Binary KiB is 1,024 bytes. Windows Explorer shows sizes using 1,024 but labels the column "KB", which means a file Windows calls 50 KB is 51,200 bytes — and a portal doing a strict bytes <= 50000 check will reject it.

This only matters when you're sitting right on the boundary, which is exactly where people land when they optimize hard against a limit.

How to confirm: find the size in bytes rather than KB. Properties on Windows shows the exact byte count in parentheses.

The fix: leave yourself headroom. Target 45 KB for a 50 KB limit and the ambiguity stops mattering. This is good practice regardless — a couple of KB of slack costs you nothing visible.

A diagnostic order that saves time

When an upload fails and you don't know why, work through it in this sequence. It's ordered so the cheapest and most likely checks come first:

1. Confirm the real format — not the extension. Fixes the majority of cases.
2. Re-read the rules for a minimum, and for a required format and color mode.
3. Check the byte count, not the rounded KB figure, against the stated limit.
4. Compute the aspect ratio and compare it with the requirement.
5. Look at the downloaded file itself — background color, rotation, obvious distortion.
6. Re-encode from scratch through a canvas-based tool. This clears format mismatches, progressive encoding and stale EXIF orientation in one step.

That last step is why "just run it through the resizer again" fixes so many mysterious rejections. You aren't changing the dimensions — you're producing a clean, baseline, correctly oriented file with no inherited metadata.

One thing worth knowing about limits

If a portal's limit is very tight, the honest constraint is that pixel dimensions matter more than compression. A 600×800 portrait squeezed into 15 KB will look bad no matter how good the encoder is, because there simply isn't enough data to describe that many pixels. A 200×260 photo at 15 KB looks fine.

So when you can't hit a target without the image turning to mush, reduce the dimensions first and compress second. Our tool will tell you when it couldn't reach a target rather than silently handing you an oversized file — but it can't create detail that the byte budget won't hold.

Related guides

• Exam photo & signature sizes: how to read the rules — the four constraints portals specify at once.
• Resize an image to an exact KB size — set any target and compress to fit.
• Passport photo dimensions by country — sizes and file limits.
• Resizing without losing quality — why downscaling is safe and upscaling isn't.