Image DPI Checker

What the metadata says and what it means

Image files carry a resolution field in their metadata, and it records an intended print size rather than anything about the image data.

Changing it alters nothing about the pixels. A 3000 pixel image tagged 72 and the same image tagged 300 are byte-identical in their image data and will print identically at the same physical size.

Which is why checking the tag is nearly useless as a quality test. The meaningful check is pixel dimensions against intended print size, and the tag can be ignored entirely.

Where the 72 DPI myth came from

Early Macintosh displays were approximately 72 pixels per inch, which matched the typographic point at 72 to the inch, so an inch on screen was an inch on paper.

That correspondence disappeared decades ago and the number persists in defaults, in software and in advice. Images exported from many web tools carry a 72 tag regardless of their content.

The result is a recurring exchange where a print supplier says a file is 72 DPI and needs to be 300, the designer changes the tag, and both parties believe something has been fixed. What actually mattered was whether the pixel count was sufficient, and the tag never told anyone that.

The check that is worth running

Pixel width divided by print width in inches, and the same vertically. If both exceed the required resolution, the file is adequate.

If they differ, the aspect ratio does not match and something will crop. If they are below the requirement, more pixels are needed and no metadata change will supply them.

For a supplier's minimum requirement, apply their figure at the ordered size rather than at whatever the file is tagged. That is the calculation they are actually performing when they accept or reject.

When the tag does matter

Placing an image into a layout application uses the tag to determine the initial size on the page. An image tagged 72 arrives four times larger than one tagged 300 and has to be scaled.

That is a convenience rather than a quality issue, and it is the one legitimate reason to set the tag correctly. A library of images tagged at their intended output resolution places at the right size without adjustment.

Some print workflows also validate the tag as a proxy check, which is why files get rejected for it despite the tag being meaningless. Setting it to match the intended output removes the friction even though it changes nothing about the image.

Reading it without special software

Both Windows and macOS show pixel dimensions in the file information panel, and both show the resolution tag in the more detailed view.

Command line tools report everything: ImageMagick's identify command gives dimensions, resolution, colour space and profile in one line.

The figure to record is the pixel dimensions. Anyone building a library of print assets is better served by a filename or a catalogue field carrying the pixel dimensions than by relying on a metadata field that most software writes carelessly.

For anyone handling files from clients or contributors, a short intake note prevents most of the back and forth. Asking for the pixel dimensions and the intended print size, rather than asking for a file at 300 DPI, gets a usable answer from people who do not work in print daily. The second phrasing invites someone to change a metadata field and send back the same file, which is the loop this whole topic generates.