Understanding DPI, PPI, and Resolution Once and for All

Updated on April 11, 2026

Every designer has been there: you export an image at "300 DPI" for print, send it to the printer, and still get a fuzzy result. Or you resize a photo to 72 PPI for web and wonder if that number even matters. The confusion is understandable because DPI and PPI are thrown around interchangeably in software menus and tutorial articles, but they actually describe different physical phenomena. Getting this wrong wastes hours, ruins print jobs, and leads to over-compressed web images. Let's sort it out properly.

The Core Distinction: Dots vs. Pixels

Start with the hardware. A printer lays down ink. The smallest unit it can place is a dot. DPI — Dots Per Inch — measures how many of those ink dots the printer can place within a single linear inch. A consumer inkjet at 300 DPI places 300 ink dots per inch; a professional photo printer at 2400 DPI places 2400. More dots per inch means finer detail, smoother gradients, and better color blending because modern inkjets simulate color by clustering tiny dots of different hues together (a technique called dithering).

A screen emits light through pixels. PPI — Pixels Per Inch — measures how many discrete light-emitting pixels occupy one linear inch of a display panel. A 1080p monitor at 24 inches has roughly 92 PPI. A Retina MacBook at the same physical size has 220 PPI. Same physical area, vastly different pixel density.

So DPI is a property of output devices that use dots (printers, typesetters). PPI is a property of display devices and, by extension, digital images when they're assigned a display context. They are not the same unit, and conflating them is where most confusion begins.

Where the Confusion Comes From: Image Metadata

When you open Photoshop and check Image → Image Size, you see a field labeled "Resolution" measured in pixels/inch. This value is stored in the image file's metadata — the EXIF or JFIF header, depending on format. That number tells printing software: "when you print this, how many of my pixels should fit in one physical inch?"

Here's the part that trips people up: that metadata value has absolutely zero effect on the pixel grid itself. A 3000×2000 pixel image with 72 PPI metadata and the exact same image with 300 PPI metadata contain identical pixel data. They look identical on your screen. They will look identical if you put them side by side in a browser. The number is purely instructional metadata for print workflows.

When you send the 72 PPI version to a printer set to "print at native resolution," the software interprets it as: "fit 72 pixels per inch," meaning the image prints at 3000÷72 ≈ 41.7 inches wide. That's why it looks massive and blurry. Send the 300 PPI version and it prints at 3000÷300 = 10 inches wide — crisp, at the intended size. Same pixels. Different instruction.

Changing the PPI metadata without resampling is just relabeling the box. It changes how the image is interpreted by print drivers, not what's actually inside.

Resolution: The Actual Meaningful Number

Resolution in the truest sense is just pixel count — total pixels in each dimension. A 4000×6000 image has more resolution than a 800×1200 image because it contains more discrete units of information. Everything else flows from this.

Whether that resolution is "enough" depends entirely on what you're doing with it:

  • Print at 300 DPI: Divide pixel dimensions by 300 to get printable inches. 3000px wide ÷ 300 = 10-inch print. Most professional print work calls for 300 DPI because that's around the threshold of human visual acuity at normal reading distance (roughly 10–12 inches from the eye).
  • Large-format print: Billboards and trade show banners are typically 72–150 DPI because they're viewed from 10+ feet away. The human eye can't resolve 300 DPI differences at that distance.
  • Screen display: The metadata PPI value is irrelevant. Browsers render images pixel-for-pixel unless CSS scales them. A 600×400 image embedded at 600×400 CSS pixels on a standard-density screen shows every pixel. On a Retina screen (2x device pixel ratio), the browser may show it at 300×200 CSS pixels unless you specify otherwise, which is why responsive image techniques exist.

How Resizing Actually Works — and Where Quality Gets Lost

This is where understanding the mechanics pays off most directly. When you resize an image, you're doing one of two things: resampling (changing actual pixel count) or rescaling (changing display/print size without touching pixels).

Downsampling (reducing pixel count) requires the software to throw away pixels and interpolate the remaining ones. A well-implemented Lanczos or bicubic algorithm produces excellent results — it analyzes the surrounding pixel neighborhood and computes the most visually accurate reduced value. The image loses absolute resolution but can look sharp because you're just reducing what's there.

Upsampling is the painful direction. When you scale a 500×500 image up to 2000×2000, you're asking the software to invent 3.75 million new pixels from the information in 250,000 original ones. Bilinear and bicubic algorithms smooth the result, which is why upsampled images look blurry rather than blocky — the blur is the algorithm's best guess at what the missing data would have been. Modern AI-based upscalers (Topaz Gigapixel, Stable Diffusion upscalers, ESRGAN) do dramatically better by using learned priors about what detail typically looks like, but you're still hallucinating data that wasn't there.

The practical implication: you cannot rescue an 800×600 photo for a full-bleed A3 print by bumping the PPI to 300. The metadata will say 300, the math will work out, but the printed result will be blurry because the actual pixel grid doesn't have enough information to support 300 distinct ink decisions per inch across that area.

Format Conversion and What It Does to All This

Format conversion adds another layer. JPEG, PNG, WebP, TIFF — these all handle pixel data differently, and conversion between them can interact with resolution in non-obvious ways.

JPEG uses lossy compression. Every time you save as JPEG, the DCT (Discrete Cosine Transform) compression algorithm discards frequency information, particularly in high-contrast edges and fine textures. At quality 95 this loss is nearly imperceptible; at quality 60 you'll see blocking artifacts in gradients. Critically: if you take a print-ready 300 PPI TIFF, convert to JPEG at quality 70, and print it, you may see compression artifacts even though the pixel count hasn't changed.

PNG is lossless. Converting a JPEG to PNG doesn't recover lost data — it just stores the existing (already degraded) pixels without further loss. The file size gets larger; the image quality doesn't improve. This is a common misconception.

TIFF (especially with LZW compression) is the lossless format of choice for print pre-press because it preserves every pixel precisely, supports CMYK color spaces, and handles 16-bit per channel depth for maximum tonal range. If you're preparing something for professional offset printing, TIFF in CMYK at 300 PPI is the standard handoff format.

WebP deserves attention for screen use. It achieves roughly 25–35% smaller file sizes than JPEG at equivalent visual quality. The PPI metadata in a WebP file is as irrelevant to screen rendering as it is in any other screen format — but the file size savings are real and measurable in page load performance.

A Practical Decision Framework

Strip away the jargon and the decisions simplify considerably:

Preparing for print? Calculate required pixel dimensions first: multiply the intended print size in inches by 300 (or whatever your print provider specifies). Need a 10×8 inch print at 300 DPI? You need 3000×2400 pixels. Check if your source image has those pixels. If it does, set the PPI metadata to 300 and don't resample. If it doesn't, you either print smaller, accept lower quality, or use an AI upscaler and accept that you're approximating.

Preparing for web? Forget the PPI number entirely. Think in pixel dimensions only. If your layout places an image at 800 CSS pixels wide, provide an 800px image for 1x screens and a 1600px image for 2x (Retina) screens via srcset. Compress with WebP at quality 80 and see if it's visually acceptable before bumping higher.

Cropping? Cropping removes pixels without resampling — it's non-destructive to the remaining pixel data. A crop from a 4000×3000 image to 2000×2000 gives you a perfectly sharp 2000×2000 image. Just be aware you've halved the printable area if you were targeting a specific print dimension.

The One Number That Actually Matters

After all of this, it comes down to a simple principle: pixel count determines information; PPI/DPI metadata determines how that information maps to physical space. Every tool in your workflow — Photoshop, GIMP, Affinity Photo, an online image resizer — gives you controls for both. Understanding which knob does what stops you from adding metadata without adding pixels, or upsampling unnecessarily when a rescale would do.

The next time a client sends you a "300 DPI" image that looks terrible, check the actual pixel dimensions first. And the next time you're preparing something for print, start with the math — inches × DPI = pixels required — before you even open the file. Everything else is a label on the box.