Is DPI the same thing as PPI?

In this context they are used interchangeably and both name the same field. Strictly, dots per inch describes a printing device laying down ink and pixels per inch describes a grid of samples, and a photographic printer may put several dots down per pixel. Nothing in a still image file distinguishes them, so a tool that reads the tag has one number to work with whatever it is called.

Two programs report different resolutions for the same JPEG. Which is right?

Both are reading a real field; the file is carrying two of them. A JPEG can hold a density in its JFIF header and another in its Exif resolution tags, and nothing forces the pair to agree. Applications differ about which they believe. When they disagree the safe move is to set the figure explicitly rather than to work out which program is being read.

Why is 5 mm not exactly 59 pixels at 300 DPI?

Because 5 ÷ 25.4 × 300 is 59.055, and a file cannot hold a twentieth of a pixel. Rounding to the nearest whole pixel makes it 59, which measures back to 4.996 mm. The error is under four microns and is reported rather than hidden — every millimetre figure on the site is shown with the pixel width it will actually produce.

Does setting the resolution field change the photograph?

Not here. On this site the figure is an input to arithmetic and nothing else: it converts a physical width into a pixel width and is then done. It is not written into the exported file, and it does not resample anything. A tool whose product is the density tag itself would behave differently, and that is a separate job from this one.

Border widths in millimetres

A border measured in millimetres is a claim about paper. Turning it into pixels takes a second number, and most of the confusion around print margins comes from that number being invisible.

One equation, three quantities

Pixels, physical distance and resolution satisfy a single relation: pixels = millimetres ÷ 25.4 × dots per inch. Fix any two and the third follows. That is the whole of the arithmetic, and everything awkward about millimetre borders comes from the fact that one of the three is usually sitting in a metadata field nobody has looked at.

The practical consequence is that the phrase “a 5 mm border” does not describe a file. It describes a file plus an intention about how large that file will be reproduced. Two photographs with identical pixel dimensions, one destined for a postcard and one for an exhibition print, need different pixel widths to show the same 5 mm of white.

5 mm resolved against the resolutions files actually declare
Declared	5 mm in pixels	Measures back as
72 DPI	14 px	4.94 mm
96 DPI	19 px	5.03 mm
150 DPI	30 px	5.08 mm
240 DPI	47 px	4.97 mm
300 DPI	59 px	5.00 mm
600 DPI	118 px	5.00 mm

Where the figure actually lives

Three containers carry a resolution in three different shapes, and a tool that reads physical units has to know all three.

JPEG, JFIF header

The APP0 segment at the front of most JPEGs carries a units byte followed by an X and a Y density. The units byte is the important part: 1 means the densities are per inch, 2 means per centimetre, and 0 means they are an aspect ratio and carry no physical information whatsoever. A file with units 0 and densities of 1 and 1 is extremely common and says nothing about print size, though plenty of software displays it as though it did.

JPEG, Exif block

The APP1 segment holds a TIFF structure, and inside it XResolution and YResolution sit as rational numbers alongside a ResolutionUnit of 2 for inches or 3 for centimetres. A camera usually writes these; an editor usually rewrites them. When they disagree with the JFIF densities the file is internally inconsistent, and which figure an application shows you is a matter of that application’s preference.

PNG, pHYs chunk

PNG records pixels per metre rather than per inch, in a chunk that may appear before the image data. Converting is a multiplication by 0.0254, so the familiar 300 DPI is stored as 11811 pixels per metre — a number that looks arbitrary and is not. A PNG with no pHYs chunk at all is the norm rather than the exception.

This site reads all three, shows which one it found, and treats the value as an editable default. WebP, AVIF and the rest are read for pixels only; where they carry density at all it is not in a place a browser will hand over, so those files arrive with the field unset.

When a file declares nothing

This is the ordinary case, not the exceptional one. Screenshots, exports from most web tools, images pulled out of chat applications and anything that has been through a metadata stripper arrive with no density at all. The honest response is to say so and to leave the physical fields inactive, which is what happens here.

Supplying a figure is a decision about the destination rather than a discovery about the file. Photographic labs generally work at 300. Book and magazine printers frequently ask for 240 or 266. A poster viewed from two metres is perfectly well served by 150, and an office laser printer rendering a report figure is doing nothing that needs more than 200. Put the destination’s number in, and the margins follow.

Rounding, and why it is reported

Every physical width has to land on a whole pixel, so every physical width is very slightly wrong. The error is at most half a pixel, which at 300 DPI is 0.042 mm — far below what a guillotine can hold and far below what an eye can see. It is reported anyway, beside every millimetre figure, because a tool that echoes your request back at you is showing you your own typing rather than its result.

One place the rounding becomes visible is the weighted lower edge. A 10 mm side margin at 1.15 gives an 11.5 mm bottom, which is 136 pixels at 300 DPI against 118 at the sides — a ratio of 1.1525 rather than 1.15. Nothing has gone wrong; the integer grid simply cannot hold every ratio exactly, and the figures shown are the ones the file will carry.

Questions about physical widths

Is DPI the same thing as PPI?: In this context they are used interchangeably and both name the same field. Strictly, dots per inch describes a printing device laying down ink and pixels per inch describes a grid of samples, and a photographic printer may put several dots down per pixel. Nothing in a still image file distinguishes them, so a tool that reads the tag has one number to work with whatever it is called.
Two programs report different resolutions for the same JPEG. Which is right?: Both are reading a real field; the file is carrying two of them. A JPEG can hold a density in its JFIF header and another in its Exif resolution tags, and nothing forces the pair to agree. Applications differ about which they believe. When they disagree the safe move is to set the figure explicitly rather than to work out which program is being read.
Why is 5 mm not exactly 59 pixels at 300 DPI?: Because 5 ÷ 25.4 × 300 is 59.055, and a file cannot hold a twentieth of a pixel. Rounding to the nearest whole pixel makes it 59, which measures back to 4.996 mm. The error is under four microns and is reported rather than hidden — every millimetre figure on the site is shown with the pixel width it will actually produce.
Does setting the resolution field change the photograph?: Not here. On this site the figure is an input to arithmetic and nothing else: it converts a physical width into a pixel width and is then done. It is not written into the exported file, and it does not resample anything. A tool whose product is the density tag itself would behave differently, and that is a separate job from this one.