Image pixels, file size and DPI: which setting should you change?
Understand width and height, KB limits and print density, with concrete examples for resizing an image without confusing DPI with detail.
A passport portal asks for a photo at 300 DPI. You open the image properties, see 72 DPI, type 300, save, upload — and the site rejects it again, this time complaining about pixel dimensions. Nothing you changed actually changed the image. DPI is the single most misunderstood field in image metadata, and once you see what it does and does not control, the whole resize-crop-compress decision gets simpler.
Three different measurements
An image file carries three numbers that people constantly mix up:
| Measurement | Example | What it actually controls |
|---|---|---|
| Pixel dimensions | 1200 × 1800 px | How much raster data exists. This is the real image. |
| File size | 180,000 bytes | How much encoded data must travel over the network |
| Print density | 300 DPI | A hint for printers: how large to draw those pixels on paper |
Only the first one describes the picture. File size is a consequence of pixels, content and encoding. DPI is a tag — two bytes of metadata in the file header saying "assume this many pixels per inch when printing."
What DPI actually does
The 4 × 6 inch arithmetic
DPI never adds or removes detail. It converts between pixels and physical size, and nothing else. The arithmetic is worth doing once by hand:
A 1200 × 1800 pixel image at 300 pixels per inch prints at 4 × 6 inches. Change the tag to 600 and the printer assumes 2 × 3 inches — same 1200 × 1800 pixels, half the physical size, twice the density. Change it to 72 and you get a 16.7 × 25 inch poster made of the same pixels, which will look soft because those pixels are now spread thin.
The useful direction of that formula is the reverse one: multiply the target paper size in inches by the DPI you need, and you get the minimum pixel count you must start with.
Now the part that explains the rejection: editing the DPI tag does not change the file size, and it does not change the pixel dimensions. If a portal checks for 600 × 800 pixels, a 300 DPI tag on a 400 × 533 image does nothing. If a portal enforces a byte limit, changing DPI frees exactly zero bytes.
DPI versus PPI versus optical resolution
DPI is often written as PPI (pixels per inch) in technical documentation, which is the more accurate term for image density. The distinction matters only when you meet a scanner spec that talks about optical resolution — that one is about real captured detail.
When DPI matters and when it does not
| Situation | Does DPI matter? | What to change instead |
|---|---|---|
| Viewing on a phone, laptop or projector | No | Nothing; pixel count sets the on-screen size |
| Uploading to a web form that checks dimensions | No | Resize to the required width and height |
| Uploading to a form that checks the DPI tag | Yes | Set output DPI, and verify the saved file |
| Printing a photo at a specific paper size | Yes | Ensure enough pixels: inches × DPI |
| Submitting a scan to a government portal | Sometimes | Follow the stated scan resolution when re-scanning |
The last two rows are where DPI earns its keep. Printing at 4 × 6 inches needs 1200 × 1800 pixels at 300 DPI — and if you only have 800 × 1200 pixels, no DPI tag rescues the print. Conversely, a scan intended for print should be captured at a resolution that produces enough pixels for the target paper size, then the DPI tag just records what you already did.
| Paper size | At 150 DPI | At 300 DPI |
|---|---|---|
| 4 × 6 in (10 × 15 cm) | 600 × 900 px | 1200 × 1800 px |
| 5 × 7 in (13 × 18 cm) | 750 × 1050 px | 1500 × 2100 px |
| A4 (8.27 × 11.69 in) | 1240 × 1754 px | 2480 × 3508 px |
| Letter (8.5 × 11 in) | 1275 × 1650 px | 2550 × 3300 px |
Read that table left to right when you are deciding how to scan. A4 at 300 DPI is what most scanners call their default, and it is why a single scanned page arrives at roughly 2480 × 3508 pixels — a detail that matters when you start compressing.
Why the tag is free and the pixels are not
People reach for DPI first because it feels like the cheapest fix: one number in a dialog box, one save. And it is free in exactly one sense — because it stores no data. The whole field is a pair of rational numbers in the file header, a few bytes, and rewriting them leaves the compressed image data completely untouched.
That asymmetry is the entire story. Adding pixels means encoding more image data, which costs arithmetic and storage. Declaring a density costs nothing, which is precisely why it cannot improve a photo. When a requirement is phrased in DPI, translate it into pixels before you decide the requirement is hard to meet; when it is phrased in pixels, DPI is irrelevant to you.
Resize, crop, or neither
Why a 1200 × 800 image cannot fill a square
Resize changes the pixel dimensions. With the aspect ratio locked, fitting a 1200 × 800 image inside a 600 × 600 box gives 600 × 400. That is correct behaviour: it cannot fill a square without either leaving blank space or cutting content.
Cropping for ratio without losing the face
Crop removes pixels from the edges. When a portal demands a square or a specific portrait ratio, crop deliberately — decide what must stay in frame, then resize the crop. Never stretch a face to hit a dimension; the distortion is what gets a photo rejected by a human reviewer, and no DPI value hides it.
A useful habit for ID-style photos: crop with the eye line in the upper third and a margin above the head, then resize. If you crop tight to the chin and crown to gain pixels, the result usually fails the reviewer's framing check even when the file passes every automated one.
Common portal mistakes
Five ways a photo gets rejected
- Setting DPI and calling it done. The dimensions are unchanged, so an exact-pixel check still fails.
- Upscaling to hit a minimum. Going from 400 × 533 to 600 × 800 invents interpolated pixels. It creates no genuine detail; faces get softer, and sharpening afterwards just adds halos. If a real minimum applies, re-photograph at higher resolution.
- Compressing before resizing. Compression artefacts get magnified by the later resize. Always resize first, compress last.
- Assuming the file manager is telling the truth about size. It rounds, and it may show KB where the site means KiB.
- Trusting a DPI value that the receiving system ignores. Density metadata support varies by format and by reader. AttachReady writes explicit DPI for JPEG and PNG; that is not a promise that every portal reads it the same way. After setting it, open the output and check what was actually stored with image inspection.
A workable order of operations
Read every rule before you touch the file
- Read the receiving site's rules and write down all of them: format, pixel dimensions, byte limit, and any DPI requirement.
- Crop only if the required ratio demands it.
- Resize to the required pixel dimensions.
- Set the DPI tag only if the destination asks for it — and verify the saved value.
- Compress to the byte limit last, then inspect the output's real width, height, format and byte count.
For background on the pixel-versus-physical-size relationship, see Adobe's image size documentation. But specific exam, visa or passport rules must come from the receiving organisation — a generic "300 DPI is good" recommendation will not tell you what that particular portal validates.
If you are also fighting a byte limit, the compression workflow covers the KB/KiB trap and the JPEG quality curve.