A form that asks for “300 DPI” is often not asking for 300 of anything in the pixel data. DPI is a density label attached to a file, while pixel dimensions and file bytes are the numbers an ordinary upload check reads. Knowing which one a form means is the difference between resizing a photo and retagging it instead of resizing it.
What “DPI” is stored as
In a JFIF-encoded JPEG, density lives in the APP0 header: a units byte, then horizontal and vertical density. The JFIF 1.02 specification defines units 0 as no units (aspect ratio only), 1 as dots per inch and 2 as dots per cm. In a PNG, the equivalent is the optional pHYs chunk, which stores pixels per unit on each axis plus a unit specifier — 0 for unknown, 1 for the metre. So a PNG claiming 300 DPI actually stores 11811 pixels per metre.
Both are metadata. Neither changes how many pixels exist. Exif can carry its own XResolution, YResolution and ResolutionUnit tags, so a JPEG may hold both Exif and JFIF values, and a print pipeline may read either. The PNG specification is explicit that when the unit is unknown the chunk describes only pixel aspect ratio, and that if pHYs is absent pixels are assumed square while the physical size of each pixel is unspecified.
That is why a browser can display a 6000 × 4000 photo and a 600 × 400 image at the same on-screen width: the page sets the width in CSS pixels. The CSS definition of a pixel (1/96th of an inch) describes a logical relationship for layout, not a promise about the file's print density.
A measurement, not an assertion
To test what the label actually does, the same 1200 × 800 image was encoded twice with identical encoder settings, changing only the density value. The pixel data hashed identically before and after.
| File | Pixels | Density label | File size |
|---|---|---|---|
| JPEG, quality 82 | 1200 × 800 | 72 DPI | 64,543 bytes |
| JPEG, quality 82 | 1200 × 800 | 300 DPI | 64,543 bytes |
| PNG | 1200 × 800 | 72 DPI | 6,796 bytes |
| PNG | 1200 × 800 | 300 DPI | 6,796 bytes |
Method: a generated test image was encoded locally with Pillow, reading back the decoded pixel bytes to confirm they were unchanged. This is a controlled test of one encoder, not a benchmark of any upload portal or of Image KB Reducer. Other encoders may write a differently sized metadata block, so expect small byte differences in other software — but never extra detail.
The practical consequence is blunt: raising the DPI value of a fixed-pixel image cannot satisfy a pixel-dimension requirement, cannot improve sharpness, and does not meaningfully change the byte count. It only changes the label a print pipeline may read.
When the label is the point
Some print and prepress workflows do read embedded density to decide physical output size. Photo kiosks and print shops may use it. A form that specifies millimetres and a DPI is telling you how many pixels it wants, and may additionally check the tag. Setting the density is legitimate there; just do not expect it to substitute for pixels.
Image KB Reducer's passport tool is built for exactly that case: it converts a millimetre size plus DPI into pixels, centre-crops to the required aspect ratio and writes the DPI into the file. Its own documentation distinguishes a real density tag from “just a pixel count”, and states that it does not fix background, pose or expression. That description is the product's published behaviour; this article did not execute the browser tool against a live portal.
Turning millimetres and DPI into pixels
The arithmetic is one line. Pixels = millimetres ÷ 25.4 × DPI, rounded to the nearest whole pixel on each axis.
| Physical size | 300 DPI | 600 DPI |
|---|---|---|
| 35 × 45 mm | 413 × 531 px | 827 × 1063 px |
| 25 × 35 mm | 295 × 413 px | 591 × 827 px |
Read it backwards to check a claim: 413 px at 300 DPI is 34.97 mm, which rounds to 35 mm. If a whole batch came back a pixel short, check rounding order first — round only at the end, and confirm against the receiving instructions rather than this table.
If a form gives DPI but no physical size, the requirement is incomplete. Density alone does not determine a pixel count: 300 DPI on a passport photo and 300 DPI on a poster imply very different pixel dimensions. Ask for the missing dimension or find the service's published pixel range instead of guessing.
Four kinds of rule, four different actions
- Pixels only (“minimum 600 × 600”). Resize to those dimensions. The DPI label should not affect acceptance; the portal's own instructions decide.
- Millimetres plus DPI. Convert with the formula, resize, and set the tag. Crop to the required aspect ratio rather than stretching.
- DPI only. Incomplete. Do not invent a physical size; seek the pixel or millimetre figure.
- Bytes only. Reduce pixels and quality within the format the form accepts. A DPI change will not meaningfully change the byte count.
An order of operations that survives re-encoding
- Inspect the original first. Use Image Info to see stored dimensions, the dimensions after EXIF orientation, colour depth and which metadata blocks exist. A sideways phone photo can look correct in a viewer while its stored width and height are swapped.
- Fix dimensions and crop before chasing bytes. If the form pins pixels, use Exact Size + Dimensions so dimensions win over the byte target and the tool reports any shortfall honestly rather than shrinking the image behind your back.
- Set density only if the rule names a physical size. The Passport Photo Resizer takes millimetres and DPI and outputs the matching pixel dimensions.
- Then compress, keeping dimensions fixed. Compress to Exact Size searches for quality that fits under the byte ceiling; with resizing disallowed it holds the dimensions and tells you the closest achievable size.
- Re-inspect the exported file. Some operations re-encode and drop blocks. If a print pipeline needs the density tag, confirm it is still present after your final save — and remember that stripping metadata is sometimes the goal, not a side effect.
Checks before you upload
- Pixel dimensions match the rule, measured after orientation is applied.
- File bytes are under the stated ceiling, read from the saved file rather than a preview.
- Format is the one the form accepts, with the correct real encoding — not a renamed extension.
- Density tag present only where a physical-size rule requires it, and verified after the final export.
- Small text, signatures and fine edges are still legible at normal viewing size.
- Your original is untouched and kept separately.
Limits of this guide
No upload to any portal was attempted for this article, so no acceptance or rejection is claimed. Portals differ: some read density for print output, some ignore metadata entirely, and some reject files for reasons unrelated to either number. The arithmetic above is reproducible; the acceptance behaviour of a specific service must be read from that service's current instructions.
For this piece the privacy statement is taken at face value from the vendor: browser-local processing is Image KB Reducer's published description, not a finding of this review. Sensitive documents belong only in tools whose handling you can justify independently.
Sources and scope
Sources checked 24 October 2026. Keyword interest in questions such as “does DPI matter for uploads” is a hypothesis about reader intent, not a measured search volume.
- W3C PNG (Third Edition) — §11.3.4.3 defines the
pHYschunk, its unit specifier and the meaning of an absent chunk. - JFIF Version 1.02 —
APP0units field, X and Y density values, dots-per-inch and dots-per-cm definitions. - CSS Values and Units Level 4 — absolute units, including 1px = 1/96th of 1in in CSS layout.
- Pillow image file formats — the
dpisave parameter documented for JPEG and PNG, used for the controlled test above. - Image KB Reducer tool directory, Image Info, Passport Photo Resizer, Exact Size + Dimensions, Compress to Exact Size — published tool behaviour quoted, not independently benchmarked.