What the number in the field means
Dots per inch is a statement about paper. It says how tightly the pixels already present should be laid down when the image is printed, and it has no effect whatsoever on a screen, where the operating system uses its own density and ignores the file entirely. This is why an image can look identical before and after the field is changed and still be accepted by a submission portal that rejected it an hour earlier.
The strictly correct term for a file is pixels per inch; dots per inch belongs to the printer, whose dots are smaller than pixels and are laid several to a pixel. Every piece of software in this chain uses the two interchangeably, and this site follows that usage rather than correcting it at the point where a visitor is trying to satisfy a form.
Where the number is kept
Three containers, three storage locations, and one shared habit of disagreeing with each other. What this tool writes, and where:
| Container | Field | Unit | Written here |
|---|---|---|---|
| JPEG | JFIF APP0 density | per inch or per cm | yes |
| JPEG | Exif XResolution / YResolution | per inch or per cm | yes |
| PNG | pHYs chunk | pixels per metre | yes |
| TIFF | IFD resolution tags | per inch or per cm | not yet |
| WebP | none defined | — | no |
Where a JPEG carries an Exif block with no resolution tags in it, the tags are appended by writing a fresh first directory at the end of the block and re-aiming the header’s pointer at it. Every existing offset in that block stays valid because nothing inside it moves, which matters: a sub-directory pointer left dangling by a careless insertion produces a file that opens in some readers and not in others.
When rewriting the field is the entire job
Three cases, and they cover most of the traffic that reaches this page. A print vendor’s preflight has rejected a file for resolution while the pixel count is comfortably large enough. A submission portal specifies 300 dpi for a scanned document. A layout program has placed an image at four times the size intended because the file claims 72.
In all three the picture is already right and only the label is wrong. Print-size-only mode is the correct operation, the export is the same photograph, and the exported file differs from the original by a handful of header bytes.
What this mode cannot do:
- Setting a higher number never adds detail. If the pixel count is genuinely too low for the print size, the field will say 300 and the print will still show the pixel grid; the panel prints the achievable resolution so you can see that coming before the file is sent.
- The field can only be written where the container defines one. A WebP has no such field, and a TIFF's tags are not editable in this release, so both are declined by name rather than silently exported unchanged.
Questions this raises
- Is DPI stored inside the image, or is it something the printer decides?
- It is stored inside the file, in a header field, and the printer reads it as a default. A JPEG keeps it twice — in the JFIF segment and in the Exif block — and a PNG keeps it once, in a pHYs chunk, expressed in pixels per metre. Layout software reads that field when it places the image and sizes the frame accordingly. Nothing about the pixels changes when the field does.
- Why write the number in two places in a JPEG?
- Because readers disagree. Image editors tend to trust the Exif resolution tags; a good deal of print and layout software reads the JFIF density fields; some read whichever they find first. A file whose two fields disagree opens at one size in one application and another size in the next, which is a genuinely hard bug to diagnose. This tool writes both and writes them to match.
- What happens to a file with no resolution recorded at all?
- The panel says so, and treats it as 72 dpi purely so that a print size can be displayed. That is an assumption made by this page, not a fact about the file, and it is labelled as one. Exporting in print-size-only mode inserts the field for real: a JFIF segment is created if the JPEG lacks one, and a pHYs chunk is added ahead of the first IDAT if the PNG lacks one.
- Can the resolution be written into a WebP, a GIF or a TIFF here?
- Not in this release. WebP has no standardised resolution field at all, so there is nothing to write. TIFF does have resolution tags in its IFD and updating them is planned, but it is not built yet and the panel refuses rather than pretending. Saving a copy as JPEG or PNG in resample mode is the way through for now.
- Does rewriting the field re-compress the JPEG?
- No. The segment structure ahead of the scan is edited and the entropy-coded data after it is copied verbatim, so the compressed image payload in the exported file is bit-for-bit the file you opened. That is the whole reason this mode exists separately from the resampler.