The request always arrives the same way. Someone needs a photo for a visa application, a poster for a print shop, or a logo for a manufacturer, and the specification says 300 DPI. They open the file, find it says 72, and reasonably conclude that something is wrong with the image.
Almost nothing is wrong with the image. The number they are looking at is not a measure of quality, and in most files it is not even a measure of anything. It is a note.
An image does not have a size
A digital image is a grid of pixels. That grid has a width and a height in pixels, and those two numbers are the entire content of the file. There is no inch anywhere in it.
DPI, or more precisely PPI, is the exchange rate between that grid and the physical world. It answers one question: when something has to make physical marks on paper, how many pixels should it pack into each inch? Divide the pixel dimensions by that rate and you get a physical size:
3000 x 2000 pixels at 300 DPI -> 10 x 6.67 inches
3000 x 2000 pixels at 72 DPI -> 41.7 x 27.8 inchesSame file. Same pixels. Same detail. Two different instructions about how large to print it.
This is why “my image is only 72 DPI” is rarely the problem it sounds like. The file was never low quality; it was carrying an instruction to print enormous, which nobody intended and which the print shop’s software correctly refused. Correcting the tag with a tool like Change Image DPI fixes the instruction without altering a single pixel of the picture.
Where the number physically lives
It helps to know that the tag is a genuinely small thing, because that makes it obvious why editing it is harmless.
In a PNG, density lives in a chunk called pHYs. It stores pixels per metre rather than per inch, along with a byte saying which unit is meant. The whole chunk is always 21 bytes, no matter what value it holds, and the spec requires it to sit after the header and before the image data. Setting a PNG to 300 DPI means writing round(300 / 0.0254) into it, which is 11811 pixels per metre.
That conversion is worth pausing on, because it is the one place a rounding error exists. An inch is exactly 0.0254 metres by definition, but 11811 is a whole number and the exact value is not, so reading it back gives 299.9994 DPI rather than 300. The error is 0.0002 percent. On a 10 inch print that is a discrepancy of about six ten-thousandths of an inch, which is far below what any printer can resolve and comfortably below what any preflight check inspects.
In a JPEG, the number lives in the JFIF header near the start of the file, as a units field and an X and Y density pair. When that header is missing, as it often is on files straight out of a camera, an 18-byte JFIF segment can simply be inserted after the start-of-image marker, which is where the spec says it belongs.
The awkward part is that a JPEG can say it twice. Cameras write EXIF tags called XResolution, YResolution and ResolutionUnit, and plenty of software, Photoshop included, trusts EXIF over JFIF when both are present. A file can therefore have a perfectly correct JFIF density and still display the old value, which is the most common reason a DPI change appears to have silently failed. Any tool that claims to set DPI on a JPEG has to keep both in agreement, or it will look broken in precisely the print workflow it was built for.
Resizing and rescaling are different operations
Here is the distinction that most of the confusion collapses into.
Changing the DPI tag edits metadata. The pixel grid is untouched, the file size barely moves, and the only thing that changes is the physical size the file asks for.
Resampling changes the pixel grid. Making an image physically larger at the same density means inventing pixels that were never captured, by interpolating between the ones that were. Making it smaller means discarding pixels and blending what remains. Both are lossy, and the first one cannot add detail, because the detail was never recorded. This is what Resize Image does, and it is the right operation when the pixel count genuinely needs to change.
A “resample” option that keeps the physical print size constant is the combination of the two: it holds inches fixed and re-renders the grid at the new density, so going from 72 to 300 DPI at a constant physical size multiplies the pixel count by roughly 4.17 in each direction. The result is a much larger file that is not sharper, because the extra pixels are interpolated rather than observed. It is occasionally what a workflow demands. It is almost never what someone means when they say a print shop asked for 300 DPI.
The sum that actually decides print quality
Since DPI is only an exchange rate, the useful question never involves the tag at all:
pixels available / inches wanted = the DPI you will actually getA 1200 by 1800 pixel photo printed at 4 by 6 inches gives 300 DPI, whatever the file currently claims. The same photo printed as an A3 poster gives about 75, and no amount of editing metadata will change that, because the detail to fill an A3 sheet was never captured.
This is why passport and visa portals are specified the way they are. A requirement like “35 by 45 millimetres at 600 DPI” is a pixel-count requirement wearing physical clothing: it works out to 827 by 1063 pixels, and a photo with fewer pixels than that cannot satisfy it however it is tagged. A Passport Photo Maker exists to hit those combinations exactly, because getting the crop right and the density tag right and the pixel count right at the same time is fiddly to do by hand.
Where DPI stops being advisory
For most of a file’s life the tag does nothing. A browser lays out an image from its pixel dimensions and the surrounding CSS, and never reads the density header at all. This is the sense in which the old advice that “web images should be 72 DPI” was always empty: it described a number no web browser has ever consulted.
The tag becomes real at exactly the moment something must decide how large a physical mark to make. A printer driver. A preflight check. And, importantly, a PDF.
PDF is a page description format, so every page has a genuine physical size measured in points, and an image placed on one has to be assigned a physical size too. That is where the density tag stops being a note and becomes a decision. Turning an image into a document with PNG to PDF is the moment the number is finally consulted for real: it determines whether your 3000 pixel wide picture lands as a crisp 10 inch image on an A4 page or overflows it entirely.
What to do when the specification says 300
Work through it in this order, and the answer is usually quick.
First, check the pixel dimensions against the physical size required. Divide one by the other. If the result is at or above the number asked for, the file is fine and only the tag needs correcting.
Second, if the result falls short, no metadata edit will help, and neither will upscaling. The honest options are to find a higher-resolution original, capture a new one, or print smaller.
Third, if the pixels are sufficient, set the tag and change nothing else. That is a metadata edit measured in bytes, it leaves every pixel exactly as it was, and it is the whole of the work.
The reason this comes up so often is that the specification is written in the vocabulary of the printer rather than the vocabulary of the file. “300 DPI” is shorthand for “enough pixels for the size I am printing”, and once it is read that way, most of the panic it causes turns out to be unnecessary.
