Last autumn I was registering a colleague for an occupational qualification exam, and the photo rules were squeezed into one line of small print: "plain, front-facing, colour photo on a white background, 295×413 pixels, JPG, no larger than 20KB". The first upload was rejected with a message that the photo dimensions did not meet the requirement. My original was 4000×3000 at 8.6MB, and when I changed the width and height in an image viewer I had also switched off keep aspect ratio, so the face was squashed, yet the system raised no error. Only on the second submission did a human reviewer send it back as wrong. The third attempt failed on file size: even after resizing it was still 420KB and would not upload. Two days of back and forth before I finally took that one line apart and understood it.
1. "Dimensions not compliant" is really three separate checks
| What the rule says | What it actually checks | The usual mistake |
|---|---|---|
| 295×413 pixels | The pixel width and height of the bitmap | Thinking it changes the print size or the number of inches |
| JPG, white background | Container format and background colour | Uploading a transparent PNG and being rejected for format or background |
| No larger than 20KB | File size in bytes, decided by pixel dimensions and compression quality together | Assuming fewer pixels is automatically enough |
| 300dpi resolution | A number written into the metadata | Changing 72 to 300 and assuming it can now be printed |
The conclusion first: registration and upload systems almost always read only pixel width and height, format and byte size, so changing dpi does nothing for them. The reverse is also true: only when a file actually goes to a print shop do you work backwards from physical size times the target dpi.
2. The arithmetic, done for you
At 300dpi a one-inch ID photo is 25×35mm. 25mm is about 0.984 inches, times 300 gives 295; 35mm is about 1.378 inches, times 300 gives 413, which is where 295×413 comes from. On the same basis:
- A small two-inch photo at 35×45mm is about 413×531 pixels
- A two-inch photo at 35×49mm is about 413×579 pixels
- Social avatars are 1:1, commonly 400×400 or 800×800
- For a web image, start from the container width: a 1200px container gets 1200×675, and anything larger just slows loading for nothing
- Images in an email signature should be 200–300px wide and under 50KB, so the recipient's inbox does not stall
The exact pixel values each system wants are whatever its official documentation says. Do not assume an ID photo is always 295×413; different exam registration portals differ a lot.
3. The workflow I use now
- Copy the requirements down as three numbers and treat them as acceptance criteria: target pixel width and height, allowed format, byte ceiling. No guessing, no trial and error.
- In Image Resizer, lock the aspect ratio, enter only the width and let it work out the height. For a spec like 295×413 that fixes both numbers, scale proportionally by the long edge first and crop the excess in an image editor. Never force both numbers.
- Watch the file size shown in the live preview. Going from 4000×3000 to 295×413 drops the byte count a lot, but it is still far from 20KB, because JPG quality is still high.
- Then use Image Compressor to bring quality down. A target like 20KB usually needs a very low setting, and after compressing you must look at the result at 100% to check for smearing on the face and blocky noise along the edges.
- Before submitting, open the result on a different device and confirm the white background is pure white rather than grey, and that extra rules such as headroom and visible ears are met. Reviewers usually reject on these details, not on pixels.
Here are the numbers I measured this time, for reference: the same ID photo resized to 295×413 was 46KB at a high quality setting and 24KB in the middle, then only dropped to 14KB further down, finally under 20KB. The point where obvious smearing appeared was around 16KB. In other words a 20KB ceiling is never solved by shrinking pixels; you have to move quality, and find the point inside the range where smearing is still acceptable.
4. Details that are easy to miss
- Shrinking is safe, enlarging is not: pulling 295×413 up to 1000×1400 only adds interpolated pixels, with soft edges and a waxy look on the face. When a requirement says at least this large, you have to start from a higher resolution original and scale down.
- The cost of a locked ratio: when the original ratio and the target ratio differ, forcing both numbers distorts the face, and some systems do not check for distortion, only the pixel count. It passes the machine and comes back from the human reviewer.
- Transparent PNG: an ID photo needs a white background, and transparent images get composited onto black or rejected outright by some systems. After removing the background, lay down white first and export as JPG.
- The EXIF orientation tag: photos shot upright on a phone carry an orientation tag, and some back ends judge by the raw width and height, so they report a dimension mismatch when the image has actually been rotated 90 degrees.
- Crop first or resize first: when background has to go, my order is crop to the target ratio, then resize to the target pixels. Doing it the other way round cuts a second ring off detail that is already lost, and the face edge breaks first.
- HEIC is not on the supported list: the iPhone default format is HEIC, while tools in this category usually handle PNG, JPG, WebP, GIF and BMP. My habit now is to save or export as JPG on the phone before starting, so I do not hit an incomprehensible error at the upload step.
- GIF and animated images: after scaling, a multi-frame image either keeps only the first frame or balloons in size. Do not mix that kind of job into a batch workflow.
- Privacy: for ID photos and screenshots containing ID card details, I do not use any channel that sends the image to a back end. Local processing is my first condition when choosing a tool, and it matters more than the feature list.
5. Common questions
Q: What is the actual difference between resizing and compressing?
Resizing changes pixel width and height; compressing changes encoding quality. When a requirement says no larger than 20KB, you usually have to do both, and doing only one rarely gets there.
Q: The requirement says 295×413. Can I upload 296×414?
Depends on the system. Strict ones reject anything but the exact value; lenient ones only check the ratio and a range. I match exactly rather than betting on leniency.
Q: The resized photo looks blurry on screen but the photo shop says it is fine?
413 pixels spread over 35mm is 300dpi. It looks small on screen and is still enough on paper. Having enough pixels and having a small preview are two different things; do not judge print quality from a screen preview.
Q: How do I handle a few dozen images at once?
Compression supports batches. I resize one at a time, and when there are a dozen or so I first check that they all share the same aspect ratio, otherwise filling in one width squashes every landscape image.
Q: How large should a web image be?
Size it to the display container width, then compress quality. Most single images are sensible at 100–200KB; above 400KB it is worth going back to check whether you uploaded the original.
Those three rejections came down to my failure to separate pixels, format and byte size as three unrelated checks. My order now is: copy the requirements into three numbers, lock the ratio and change pixels, then squeeze the bytes, then check it on another device. Once the rules are broken into items you can tick off one by one, the I changed it for ages and it is still rejected kind of waste stops happening.