Why an Image Upload Is Rejected—and How to Fix It

Diagnose in order, not at random

The expensive mistake is compressing repeatedly in the hope that something changes. Every lossy re-encode permanently degrades the image, so a person who compresses five times while guessing ends up with a file that is both still rejected and visibly worse than the one they started with. Diagnosis costs nothing; guessing costs quality.

Work through the constraints in the order they are usually enforced. Format first, because it is the most common failure and the cheapest to check. Then byte size, then pixel dimensions, then aspect ratio, then metadata, and finally anything application-specific such as filename rules or account limits. Each step is independent, and fixing the wrong one has no effect on the others.

One free diagnostic before you begin: watch when the rejection happens. If the form refuses the file the instant you select it, with no upload progress, the check ran in your browser and is almost certainly about the extension or the file size — those are the only things browser-side code can check cheaply. If the file uploads fully and then fails, the server decoded it, and the problem may be dimensions, aspect ratio, metadata, or a decode failure.

Check content, not only the filename

A filename ending in .jpg can still contain HEIC, PNG, or corrupted bytes. Strict forms examine a signature or attempt to decode the file. Renaming an extension is therefore not a conversion.

PixelConvert's preflight reads the signature locally for JPEG, PNG, WebP, HEIC, TIFF, BMP, and ICO. Unsupported or unreadable signatures are rejected before preparation.

Every image format begins with a fixed byte sequence that identifies it. JPEG files start with FF D8 FF. PNG files start with an eight-byte signature beginning 89 50 4E 47. HEIC files carry an 'ftyp' box naming a HEIF brand. These bytes are the file's actual identity, and renaming the file does not touch them.

Two situations produce mismatched files without anyone deliberately renaming anything. A download from a website may save with whatever extension the server's headers implied, which is not always what the bytes contain. And an application that exports 'as JPEG' while actually writing a different format is rarer but does happen. In both cases the file looks correct in a folder listing and fails the moment something reads it properly.

Separate bytes from pixels

A maximum of 500KB describes stored bytes. A requirement of 1200×1200 describes decoded pixels. Quality affects lossy encoding; dimensions affect the number of pixels; image content affects how well those pixels compress.

Fit mode treats width and height as maximums and preserves aspect ratio. Crop mode fills exact dimensions by removing content around a centered crop. Choose crop only when the destination explicitly requires exact dimensions and the subject is centered appropriately.

The measured counterexample below is the clearest illustration of why content matters as much as settings. The same 1200×630 sharp-text image was 33,657 bytes as optimised PNG and 49,875 bytes as JPEG at quality 70. The lossy format produced the larger file, at identical dimensions, while also degrading the text. Anyone applying the rule 'convert to JPG to reduce size' would have made this file both bigger and worse.

Watch for ambiguity in stated limits. A form that says 500 KB may mean 500,000 bytes or 512,000. If you are within a percent of the boundary, target the smaller reading. Similarly, a limit of 2 MB is occasionally enforced against the encoded upload rather than the file on disk, which can differ slightly.

Dimensions and aspect ratio are different rules

A dimension rule constrains how many pixels wide and tall the image is. An aspect-ratio rule constrains the relationship between those two numbers. A form can enforce either, both, or neither, and satisfying one does not satisfy the other.

Read the wording carefully, because three similar-looking phrasings demand different operations. 'Maximum 1200×1200' means fit inside those bounds; a 3:2 photo becomes 1200×800 and stays whole. 'Must be 1200×1200' means the canvas has to be exactly square, which requires cropping or padding. 'Minimum 1200×1200' means do not go below that, and if your source is smaller you have a genuine problem — upscaling adds pixels but no detail, and some validators detect the resulting softness.

Aspect-ratio rules usually appear for banners, profile photos, and product listings. A requirement of 16:9 does not tell you the size, only the shape. If your source is a different shape, you must crop, pad, or reshoot; scaling alone cannot change an aspect ratio without distorting the image, and no reputable tool will stretch it for you silently.

Handle privacy and feasibility

Some workflows reject files carrying unusual metadata or unsupported color information. Prepared outputs are rebuilt without EXIF/GPS data and with orientation applied. The local check reports detectable metadata categories but does not upload anything until you press Prepare.

Not every combination is feasible. A detailed lossless PNG at exact dimensions may not fit a tiny byte ceiling. PixelConvert returns a clear 422 response instead of quietly exceeding the limit.

That behavior is deliberate and worth understanding. When a tool cannot satisfy your requirements, there are three possible responses: exceed the limit and let the form reject it, silently change something you specified and let a later check catch it, or refuse and say why. Only the third is useful. A file that quietly came out at 1180×1180 when you asked for 1200×1200 will fail a dimension check you believed you had passed, and you will not know why.

When you hit a genuine impossibility, the escapes are: simplify the image content, since a busy background is what makes a file incompressible; check whether the dimension requirement is truly exact; or check whether a different accepted format fits where JPEG could not.

Corrupt and partially written files

A file that will not decode at all is a different problem from one that decodes but breaks a rule. Corruption usually comes from an interrupted transfer, a failing storage device, a download that stopped partway, or a file recovered from a damaged card.

The symptom is distinctive: the image may show a partial picture with the remainder grey or garbled, or it may fail to open in some applications while opening in others. Different decoders have different tolerance for malformed data, which is why a file can look fine in one viewer and be rejected by a server.

The fix is to obtain the file again from its source rather than to convert it. Converting a partially corrupt file usually produces a partially corrupt output, and re-saving it can make the damage permanent by discarding whatever recoverable structure remained. If the original is genuinely gone, some recovery tools can salvage the decodable portion, but the missing data is missing.

When the form is enforcing something undocumented

Occasionally every visible rule is satisfied and the upload still fails. At that point stop modifying the image, because further compression cannot fix a constraint you have not identified.

Common undocumented rules include: a minimum dimension that is never stated; a rejection of CMYK or unusual colour profiles, which appear in files that have been through print workflows; a filename restriction on spaces, non-ASCII characters, or length; a total-storage or per-account upload limit unrelated to this file; and progressive-JPEG rejection by some older validators that only handle baseline encoding.

The colour-profile case is worth testing for, because it is invisible and easy to fix. Re-saving the image as a plain sRGB file — which is what PixelConvert produces — resolves it. Trying a baseline rather than progressive JPEG is a second cheap experiment.

If none of that works, contact the organisation and ask what the requirements are. That is faster than continuing to guess, and it is information they should be able to provide.