How to Change an Image to 300 DPI Without Re-encoding It

Every guide to changing DPI opens with the same correct sentence — DPI is a label, not a property of the pixels — and then stops, as if the rest were obvious. It is not obvious. I built the DPI changer on this site and then spent an afternoon trying to break it, and the thing that broke was not the arithmetic. It was that a JPEG can hold two resolutions at the same time, in two different structures, and the program your print shop uses may read the one your tool did not touch.

This is what I measured, on real files, checked afterwards by ImageMagick, PIL and libtiff rather than by the tool that wrote them.

First, the part that is genuinely simple

A 600 × 800 pixel image printed at 72 dpi is 8.33 × 11.11 inches. The same file at 300 dpi is 2.00 × 2.67 inches. Not one byte of image data changes — the number tells the printer how far apart to place the pixels it already has. Set 600 × 800 to 300 dpi and the file comes out at exactly the size it went in: 24,135 bytes in, 24,135 bytes out, with all 23,526 bytes after the JPEG start-of-scan marker identical. That is the whole operation, and any tool that re-encodes your picture to do it has changed something it did not need to touch.

So far so uncontroversial. Here is where it stops being simple.

A JPEG can answer the question twice, and disagree with itself

JPEG stores resolution in the JFIF header — an APP0 segment near the start of the file. It can also store resolution in an EXIF block, which is a completely separate APP1 segment carrying its own little TIFF directory. Cameras, phones, Photoshop and PIL all write one or both, and nothing in the format requires them to agree.

I built a file where they do not. Same picture, JFIF says 300, EXIF says 72:

Two readers, two answers, one file. ImageMagick is the one that behaves like print preflight: it reads the EXIF directory, finds a resolution there, and uses it. A tool that rewrites only the JFIF header — which is what a lot of DPI changers do, because the JFIF fields are at fixed offsets and take ten lines of code — hands you back a file that its own UI calls 300 and ImageMagick still calls 72.

After the tool writes both stores, the same three readers agree: ImageMagick reports 300 dpi, and PIL reads 300.0, 300.0, unit 2 out of the EXIF block. The file is 24,211 bytes in and 24,211 bytes out, because both edits are in place.

PNG has the same problem in a different shape

PNG stores density in a pHYs chunk, and a PNG does not have to have one. A canvas-generated PNG does not. Here is what ImageMagick says about a PNG with no pHYs at all: 72 × 72 Undefined. It has invented 72 rather than admitting it does not know, which is why "my PNG is 72 dpi" so often means "my PNG says nothing".

Add the chunk and something more interesting happens. pHYs does not store dots per inch — it stores pixels per metre, as a whole number. 300 dpi is 11,811.02 px/m, so the file can only say 11,811, which is 299.9994 dpi. Every tool that writes a PNG has this limit, including this one. ImageMagick then displays it in the unit it stored: 118.11 PixelsPerCentimetre. Nothing is wrong; the format simply cannot express 300 exactly, and a print shop reading 299.9994 treats it as 300.

Measured on the fixtures: a 16,008-byte PNG with no density became a 16,029-byte PNG carrying pHYs at 11,811 px/m — exactly 21 bytes, the size of the chunk plus its length and CRC fields — and the IDAT payload was byte-identical. A PNG that already had a pHYs chunk was edited in place at the same length, not given a second one.

What was measured, file by file

The 1 × 1 row is in there because it is the case where a print-size readout embarrasses itself: 1 pixel at 300 dpi is 0.0033 inches, and a readout that rounds to two decimals prints "0.00". The first version of this tool did exactly that, which is why the row now scales its precision to the size.

The number nobody prints: how many pixels you are short

Setting the tag is the easy half. The half that decides whether your print looks sharp is arithmetic the tool cannot do for you, because it needs to know the print size you have in mind:

pixels needed = inches × dpi. A 6-inch-wide print at 300 dpi needs 1,800 pixels. If your file is 1,200 pixels wide, you are 600 short, and no tag will fix that — the file will print 4 inches wide at 300 dpi and look right, or 6 inches wide at 200 dpi and look soft. Resampling to 1,800 pixels does not add detail; it interpolates, and the print looks like an interpolated 1,200-pixel image, because that is what it is.

That is why this tool does not resample, and why the row states the print size your pixels can actually support instead of a number you typed. If the size is wrong for you, the honest answer is a smaller print or a better source file.

What the pages that rank get wrong

The best of the browser-side DPI tools is setdpi.com, and it is worth being straight about that: it is client-side, it does not resample, and it rewrites "the resolution fields (JFIF & EXIF for JPG, the pHYs chunk for PNG)" — the same two stores, for the same reason. If your file is a JPEG or a PNG and the two stores already agree, it will do the job.

Two gaps are real, though. The first is format: it accepts "JPG & PNG", and TIFF is the format Elsevier, IEEE and Springer actually ask for at 300–600 dpi. The second is the contradictory file: a tool that silently rewrites both stores is doing the right thing, but a visitor who cannot see that the stores disagreed has no way to know why the shop rejected the file last time.

The upload-based converters are a different problem. convert.town and imageresizeonline.com both take the file to a server to change four bytes. online-converting.com is more candid and more wrong: it puts DPI in the resize operation, so the "DPI" you type changes the pixel dimensions — which is the one thing changing DPI must not do. And imagedpi.org advertises an "Intelligent DPI Enhancer" that "optimizes image resolution using smart algorithms", which is a promise no software can keep: raising a density tag cannot add resolution, and a tool that claims to enhance it is describing resampling as if it were detail.

What this tool does not do

It does not add pixels, sharpen anything, or change the print size independently of the density — those are three different operations and only the third one is this tool’s job. It refuses WebP, GIF, BMP, HEIC and AVIF by name rather than writing a tag nothing reads. It will not invent a resolution tag in a TIFF that has none, because adding a tag to an IFD means rebuilding the directory, and a half-rebuilt TIFF is worse than a refusal.

What it does is read every place the number can hide, tell you when the places disagree, and write them all — in your browser, with the image data copied through untouched. That is a small claim, and unlike most small claims about DPI, it is one you can check with ImageMagick in a terminal.