What DPI Should Client Photos Be?

DPI in a delivered file is a stored instruction about intended print size. Changing it does not add detail, remove detail, or alter a single pixel value. Two files with the same pixel dimensions and different stored resolutions are, as images, identical.

So when a client asks for a specific figure, the reply that actually helps is a question: how big is the largest print you plan to make? Then hand over the largest pixel dimensions you have. If the pixel count is sufficient for that print, the job is done. If it is not, no metadata edit will rescue it.

A usage note that belongs to this page and is not borrowed from anyone: photographers and clients use "dpi" and "ppi" interchangeably in email, and we treat them as the same request here. Correcting the vocabulary does not get the client a file that prints well.

Resolution is defined as the number of image pixels per unit length, for example pixels per inch. Mozilla publishes that definition in its CSS reference, and it makes the rest obvious: resolution is a ratio between a pixel count and a length, not a property of the pixels on their own.

An image file can carry its own resolution figure inside it. Mozilla describes using the intrinsic resolution as specified by the image format, and states that if the image does not specify its own resolution, the explicitly specified resolution is used if one was given, and otherwise the value defaults to 1dppx, one image pixel per CSS px unit. The number is optional, and something downstream decides whether to act on it.

The W3C is more specific about what kind of information this is. In the CSS Images Module it appears in the phrase "layout-impacting metadata (such as orientation or resolution)". Resolution is grouped with orientation: both are metadata, both can change how an image is laid out, and neither is the image data itself.

Almost every article on this subject states two familiar figures as though they were standards, one for print and one for screens. On 23 September 2026 we went looking for an official source that publishes a recommended figure. We checked the Adobe pages cited below, including the photography glossary, and the web standards documents cited below. None of them states a recommended number, and the terminology pages that would define the units return errors.

That is a statement about our search on that date, not a proof that no such document exists. We are not telling you the familiar figures are wrong, and we do not claim to know where they came from. What we can say is narrower: they are convention, widely repeated, and we could not find an official publisher for them today.

This matters for one practical reason. If a figure is convention rather than a published requirement, then satisfying it by editing metadata satisfies nothing real. The thing that is real is pixel count against print size, and that you can check.

There is an operation that changes the image, and it has its own name. Adobe describes it plainly: when you add or subtract pixels, that is called resampling. Decreasing the number of pixels is downsampling and increasing it is upsampling. Adobe also states that the number of pixels in a file is directly related to image quality.

On the same page Adobe describes what the Resample control does: with it checked, "this allows you to adjust the print size and resolution independently, which changes the number of pixels in the image." Read that carefully. Leave resampling off and you are relabelling. Turn it on and you are rewriting the image, because the pixel count moves. Both happen in the same dialog box, which is why the subject confuses people.

Upsampling deserves a word of caution that follows directly from Adobe's own statement about pixel count and quality: inventing pixels does not recover detail that was never captured. If a client needs a larger print than the capture supports, the honest answer is the size it will support, not a resampled file that looks soft at arm's length.

This is our plain explanation, derived from the definition above. It is not quoted from a vendor or a standards body, so do not treat it as a cited formula.

If resolution is pixels per unit length, the three quantities are tied together by division. Pixels along an edge, divided by inches along that edge, gives pixels per inch. Rearranged: pixels divided by the resolution you want gives the print length you can make, and pixel count divided by print length gives the resolution you will get.

That is the only calculation in this subject. The pixel count is fixed by the capture and your export. The print size is chosen by the client. The resolution is whatever falls out of dividing one by the other, whatever number is written in the file header.

Here is the exchange, reduced to what to ask and what to send. It takes one email and closes the question for the whole job.

Two questions cover every row: how large is the largest print, and where will the file be used. Neither question mentions a resolution figure, and neither needs one.

Most of the confusion in a delivery thread comes from the client comparing the wrong file against a print requirement. A proof exists so the client can look through a gallery quickly and choose. A final exists so it can be printed, archived, or handed to a lab. Those jobs pull in opposite directions, so they are separate files, and saying so once in writing prevents the argument.

On clientgallery.io that separation is built in. Normal uploads are compressed in the browser into proof JPEGs sized for fast viewing, so a large gallery stays quick to scroll on a phone. Full-resolution delivery is a separate paid mechanism: you upload a full-resolution ZIP for a gallery, it stays live for three days per handoff, and you can re-upload it whenever the client needs it again, within 100 GB of standing ZIPs per account.

The plan itself is one price, $10 a month or $100 a year, unlimited under fair use. Fair use here means 1,000 photos per gallery and 250 GB of proofs on a paid account, with 5 GB on a free account.

So a client who inspects a proof and reports a disappointing resolution figure is inspecting the wrong file. Point them at the full-resolution handoff rather than editing metadata on a proof.

Put the answer in the handoff itself and you will stop having the conversation. Four lines are enough, and they go in the email or the gallery welcome note where the client will actually read them.

• State the pixel dimensions. Give the figure for your own export. It is the one fact a lab can act on.
• Name the largest print you stand behind. One sentence, taken from the arithmetic above, turns an abstract number into something the client can picture on a wall.
• Separate proofs from finals. "The gallery shows proofs sized for fast viewing. The download link carries the full-resolution files." Say which is which before they check.
• Invite the real question. "If your printer asks for a specific setting, send me the print size and I will confirm the file covers it."

Keep those four lines in a template and paste them into every delivery. The client stops asking about a number and starts telling you the print size, which is the only thing you needed from them.

• Mozilla, CSS image-resolution reference, for the definition of resolution as pixels per unit length and for an image format specifying its own intrinsic resolution. developer.mozilla.org/en-US/docs/Web/CSS/image-resolution. Fetched 23 September 2026.
• W3C, CSS Images Module Level 3, for resolution being classed as layout-impacting metadata alongside orientation. w3.org/TR/css-images-3/. Fetched 23 September 2026.
• Adobe, "Increase resolution", for resampling, downsampling and upsampling, for the number of pixels being directly related to image quality, and for what the Resample control does to print size, resolution and pixel count. adobe.com/creativecloud/photography/discover/increase-resolution.html. Fetched 23 September 2026.

Product figures come from clientgallery.io's own plan and delivery limits. The statement that no official source we could reach publishes a recommended resolution figure describes our own search on 23 September 2026 across the pages above and Adobe's photography glossary.