Image Resolution Guide: DPI, PPI and What They Mean

Image resolution is simply how many pixels your picture contains, written as width by height. A 3000 by 2000 photo holds six million of them. DPI and PPI are the two numbers people argue about on top of that, and here's the short version: DPI counts dots of ink on paper, PPI counts pixels squeezed into an inch, and neither one changes a single pixel of your file. They only describe how big those pixels get printed. For anything that lives on a screen, the DPI value stored in your file is ignored outright, because the CSS specification pins one inch to exactly 96 pixels no matter what your image claims.

That one fact clears up most of the confusion. Below you'll find where each number actually matters, the maths for working out print sizes, what to use on the web, and why the famous "72 DPI for web" advice has been wrong for about twenty years. If you just want to see what you're working with, our free image size checker reads the dimensions of any file on your own device.

What Is Image Resolution, Really?

A digital photo is a grid. Resolution is the size of that grid. When your phone says it shoots 12 megapixels, it means roughly twelve million squares of colour arranged 4032 across and 3024 down.

Everything else follows from those two numbers. How much you can crop before things fall apart, how large you can print, whether a logo stays crisp on a big monitor. It's all a question of whether you have enough pixels for the job in front of you.

What resolution is not: file size. A 4000 by 3000 photo saved as a heavily compressed JPEG might be 400 KB, while the same picture saved as PNG could be 12 MB. Same resolution, wildly different files. If you want to shrink the file rather than the grid, that's a compression job, and our image compression guide walks through the difference. Resolution and weight are separate dials, and our guide to image compression covers the second one.

What's the Difference Between DPI and PPI?

They get swapped constantly, including by software that really ought to know better. The US National Archives put it plainly in an August 2023 explainer: "Today, people use dpi and ppi interchangeably, though they are entirely different measures."

DPI is dots per inch. It's a printer term. NARA defines it as "how many dots of ink can be displayed or printed within one inch of space." An inkjet printer builds a photo out of tiny sprayed dots, and it needs several of them to reproduce one pixel's colour. That's why a printer rated at 1440 DPI is not asking you for a 1440 PPI file.

PPI is pixels per inch. NARA describes the term as the one "used by software like Photoshop to describe the pixel array of a digital file or the number of pixels of a computer monitor display." It answers a different question: if I print this grid at a given physical size, how densely packed will the pixels be?

Here's the part that trips everyone up. PPI is not baked into the pixels. It's a note attached to the file saying "print me at this density." Change it and you have changed nothing about the image data, only the size it comes out of the printer. A 3000 by 2000 photo tagged 300 PPI and the same photo tagged 72 PPI are byte-for-byte identical in the pixel grid. One will print at 10 inches wide, the other at 41.7 inches wide and looking rough.

Term	What it counts	Where it applies
Resolution	Total pixels, width by height	The file itself
PPI	Pixels per inch of output	Print size and screen density
DPI	Ink dots per inch	The printer hardware

Does DPI Do Anything to an Image on a Screen?

No. Not one thing. And this is where the "save for web at 72 DPI" advice needs to be retired.

The reason is written into the web platform itself. The W3C CSS Values and Units Module Level 4 defines the absolute length units with fixed ratios: 1in equals 2.54cm equals exactly 96px, and one CSS pixel is defined as 1/96th of an inch. That ratio never changes. It doesn't consult your monitor, and it certainly doesn't consult the DPI field in your JPEG header.

So when a browser lays out your image, it reads the pixel dimensions and nothing else. A 1200 by 800 image tagged 72 DPI and a 1200 by 800 image tagged 600 DPI render identically, pixel for pixel. The tag is dead weight on the web.

The W3C spec is worth a look for another reason. It anchors those units to what it calls the reference pixel, defined as "the visual angle of one pixel on a device with a device pixel density of 96dpi and a distance from the reader of an arm's length." At a nominal arm's length of 28 inches, that works out to roughly 0.26 mm. In other words, the whole system is calibrated to how big something looks to a person sitting at a desk, not to any particular hardware.

If you want the resolution of the display rather than the file, CSS has a separate unit for that. The W3C spec defines dppx as dots per px unit and notes that "due to the 1:96 fixed ratio of CSS in to CSS px, 1dppx is equivalent to 96dpi." You'll see it in media queries like @media (min-resolution: 2dppx), which is how a site serves sharper images to dense screens.

Where Does the DPI Number Actually Live in the File?

In a handful of bytes that have nothing to do with your pixels. And once you know which bytes, most of the weird DPI behaviour you've run into stops being weird.

The section above called PPI a note attached to the file. Here's where that note is physically written, format by format, because the storage explains the symptoms.

PNG keeps it in a chunk called pHYs. The W3C PNG Specification (Third Edition), a W3C Recommendation since 24 June 2025, defines it as three fields: pixels per unit on the X axis, pixels per unit on the Y axis, and a one-byte unit specifier. That specifier has exactly two legal values. 0 means the unit is unknown, so the numbers only describe aspect ratio. 1 means the unit is the metre.

Read that again, because it's the whole trick. PNG does not store inches. It stores whole pixels per metre, as an integer.

So 300 PPI isn't directly expressible. An inch is 0.0254 m, which makes 300 PPI equal to 11,811.02 pixels per metre. The chunk can only hold a whole number, so it stores 11,811, and anything reading it back computes 299.9994 PPI. That is why Photoshop sometimes shows a PNG at 299.999 instead of 300 and why a round-trip through two editors can nudge the figure. Nothing is broken. You're watching a rounding error in a unit conversion you didn't know was happening.

JPEG keeps it in two places, and they can disagree. This is the one that causes real confusion.

The first home is the JFIF header. JPEG File Interchange Format version 1.02, dated 1 September 1992 and hosted by the W3C, puts a units byte and two density fields in the APP0 marker segment. The units byte reads: "units = 0: no units, X and Y specify the pixel aspect ratio; units = 1: X and Y are dots per inch; units = 2: X and Y are dots per cm." Xdensity and Ydensity are two bytes each. That spec was later formalised as ITU-T Recommendation T.871, also published as ISO/IEC 10918-5, approved in May 2011.

The second home is the Exif block, and this is where the famous number comes from.

The Exif standard, published jointly as JEITA CP-3451C and CIPA DC-008-2012, defines three tags on page 37. XResolution is tag 282, "the number of pixels per ResolutionUnit in the ImageWidth direction," with a stated default of 72. YResolution is tag 283, same default. ResolutionUnit is tag 296, where 2 means inches and 3 means centimetres, defaulting to 2.

Now the sentence that explains a decade of bad advice. On XResolution the standard says: "When the image resolution is unknown, 72 [dpi] shall be designated." On ResolutionUnit it says: "If the image resolution in unknown, 2 (inches) shall be designated."

Three practical consequences fall straight out of this, and they cover most of the DPI oddities people hit.

• Two apps can report different DPI for the same JPEG. If the JFIF APP0 segment says one thing and the Exif IFD says another, what you see depends on which block that particular program reads first. Neither is lying.
• Stripping metadata resets the print size. Plenty of optimisers remove Exif by default, for privacy or for the few kilobytes. The pixels survive untouched, but the density note goes with the metadata, and the next program to open it falls back to 72. Your 10-inch print just became a 41.7-inch one. Our guide to compressing images covers what else gets dropped when you strip a file down.
• Changing DPI is lossless, and always has been. You're rewriting a few bytes of header, not touching a single pixel. Setting a file to 300 DPI does not add detail and cannot damage the image. It only changes the size it comes out of a printer.

There's a fourth consequence worth stating plainly, because it's the one people ask about most. If a client asks for "a 300 DPI image" and says nothing about dimensions, they have not actually told you anything. A 400 by 300 photo tagged 300 DPI meets the request and prints at barely more than an inch across. The number that matters is the pixel count, and the physical size you want it at. Our image resizing guide covers how to hit a target size without wrecking what you started with.

What Resolution Do You Need for Print?

Print is where PPI earns its keep, because now the pixels have to land on a physical surface.

The working standard is 300 PPI, and it isn't arbitrary. NARA traces the number back to the point where "it equated to the human eye's ability to perceive detail in an 8 x 10-inch print held at arm's length." Past that, you're recording detail nobody can see from a normal viewing distance.

US federal agencies have codified it. Under 36 CFR §1236.50, published June 2023, agencies digitising permanent records must produce image files at "a minimum of 300 ppi sized to the source document" for modern textual paper records, while photographic prints and paper records carrying fine detail require "a minimum of 400 ppi sized to the source document," with the note that higher may be necessary. Colour records have to be captured in RGB, and images must be sized to match the original document.

The tolerance is the part people miss. Those specification tables allow a variance of 2 percent, so the real floor is 294 PPI for text and 392 PPI for photographs. Come in under that and the scan fails. Agencies are also told they can go higher for records carrying very small detail, with aerial photographs and topographic maps named specifically.

And there's a catch that matters if you're buying a scanner. The number you dial into the software is not the same thing as the resolution you actually get. The National Archives makes this point directly in its own explainer on DPI and PPI, published in August 2023: "true optical resolution is not determined by the scanner settings, but by how well the device resolves the fine detail." Under 36 CFR §1236.46, federal agencies have to prove it by scanning an ISO-compliant test target and checking the result with analysis software such as OpenDICE.

Which is why a cheap scanner advertising 9600 DPI is mostly selling you a number. It will happily interpolate up to that figure. Whether the optics ever resolved that much detail is a separate question, and it's the one that counts.

The broader framework behind those rules is the FADGI Technical Guidelines for Digitizing Cultural Heritage Materials, third edition approved 9 May 2023. FADGI uses a four star rating system, and its tables set the minimum sampling frequency in PPI for each content category at each star level. Useful reading if you're scanning anything you care about keeping.

For everyday printing, here's the practical range:

• 300 PPI for photos, brochures, business cards, anything held in the hand.
• 400 PPI for photographic prints and fine detail you plan to archive, matching the federal floor.
• 150 PPI for large posters seen from a metre or more away.
• 50 to 100 PPI for banners and billboards, where nobody is standing close enough to count pixels.

Viewing distance is doing the work in that list. The further back the viewer stands, the fewer pixels per inch you need, which is why a billboard printed at 300 PPI would be an enormous waste of file.

Does px Mean Something Different When You Print a Web Page?

Yes, and this is the detail that finally makes the screen and print halves of this article fit together.

Everything above said the same thing: on screen, the DPI tag is dead weight and only pixel dimensions matter. That's true. But it raises an obvious question. If CSS hard-codes 96 pixels to the inch, and a browser can send a page to a printer, which inch is it talking about?

The spec answers this directly. The same W3C CSS Values and Units Module Level 4 that defines the reference pixel also explains that the anchor swaps depending on the output. For print media at typical viewing distances, it says, the anchor unit should be one of the physical units, meaning inches or centimetres. For screen media, including high-resolution devices, low-resolution devices and devices at unusual viewing distances, it recommends instead that the anchor unit be the pixel unit.

Read that twice, because the two halves behave in opposite directions.

• On screen, the pixel is real and the inch is notional. A CSS inch is just 96 CSS pixels. Hold a ruler to your monitor and it very probably will not measure an inch, and nothing is wrong.
• On paper, the inch is real and the pixel is notional. When a browser prints, it maps the CSS inch to an actual physical inch, so 1px becomes exactly 1/96th of a real inch on the page.

The spec adds one more consequence that explains a lot of odd printing behaviour: if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels. A printer running at 600 dots per inch has to fit a 1/96 inch CSS pixel into 6.25 printer dots, and that fraction is where hairline borders come out slightly fuzzy or thicker than you expected.

Two practical things fall out of this.

Sizing a print stylesheet in px is fine, and more predictable than people assume. Because the browser anchors to the physical inch, 96px really will be an inch wide on the paper. If anything, px behaves better in print than it does on screen, since there is no device pixel ratio muddying it.

But your images still need the pixels. This is the part that catches people. Telling a browser to print an image at 96px wide gets you a one-inch image on paper, and if that file only contains 96 pixels of actual data, you have just printed a one-inch image at 96 PPI. It will look soft, because the layout instruction and the pixel data are separate things. To land near the 300 PPI figure from the print section above, that one-inch slot wants roughly 300 pixels of real image in it.

Which is the same rule as everywhere else on this page, wearing a different hat. Layout units decide how big something appears. Pixel count decides how much detail is available to fill it. Confusing the two is where nearly every resolution problem starts, and our complete guide to resizing images covers what to do when you have the wrong number of them.

How Close Will Anyone Actually Look at It?

That list above is really one question in disguise. Every PPI target is a bet about viewing distance, and once you can put a number on the distance you can stop guessing at the PPI.

The starting point is how much detail an eye can resolve at all. Normal vision is defined around one minute of arc. Per Webvision, the University of Utah reference work hosted by the National Library of Medicine, 20/20 vision means each stroke of the test letter subtends exactly one arcminute, and the minimum angle of resolution for normal vision is one arcminute.

Turn that into a rule and you get one division:

Run it and the familiar numbers fall out on their own:

Viewing distance	Acuity-derived PPI	Typical job
12 in, a photo in your hands	~287	Photo prints, business cards
28 in, arm's length at a desk	~123	Documents, screens
3 ft, a poster on a wall	~96	Posters
10 ft, an exhibition banner	~29	Trade show graphics
30 ft, a billboard	~10	Outdoor advertising

So the 300 PPI print standard isn't a magic number. It's roughly what one arcminute works out to at the distance you hold a photograph, which is about twelve inches. And it explains why the poster and banner figures in the previous section drop the way they do.

Notice the 28 inch row too. That's the same arm's length the W3C uses to define its reference pixel, and the resulting figure lands near the 96 pixels per inch the CSS spec settles on. The web and print standards are answering the same question at different distances.

One update worth knowing, because the one arcminute figure is conservative. Ashraf, Chapiro and Mantiuk measured the real ceiling and published in Nature Communications in 2025. Against the long-accepted 60 pixels per degree that one arcminute implies, they found the eye resolves about 94 pixels per degree for black and white detail, with some individuals reaching 120. Colour detail is lower: 89 ppd for red-green and just 53 ppd for yellow-violet.

That's roughly 57 percent above the textbook number, so treat the table as a floor rather than a target. If the piece carries fine high-contrast detail, or the client has good eyes and will lean in, multiply by about 1.5 and you're covered. The yellow-violet figure also explains something printers know instinctively: colour edges tolerate less resolution than black text does.

How Do You Work Out the Pixels You Need?

One line of arithmetic. Inches times PPI equals pixels.

Want a 4 by 6 inch print at 300 PPI? That's 4 × 300 = 1200 and 6 × 300 = 1800, so you need 1200 by 1800 pixels.

Print size	At 300 PPI	At 150 PPI
Business card, 3.5 × 2 in	1050 × 600	525 × 300
Postcard, 4 × 6 in	1200 × 1800	600 × 900
A4, 8.27 × 11.69 in	2481 × 3507	1241 × 1754
Photo print, 8 × 10 in	2400 × 3000	1200 × 1500
Poster, 18 × 24 in	5400 × 7200	2700 × 3600

Run it the other way to find out how big you can go with what you already have. Divide pixels by your target PPI. A 4000 by 3000 photo at 300 PPI gives 13.3 by 10 inches, comfortably enough for an A4 print with room to trim.

Once you know the target, our free image resizer gets you there in the browser, and the complete resizing guide covers the settings that matter.

📐 Resize an Image Free →

What Does DPI Mean on an Actual Printing Press?

Something different again, and this is where the term came from in the first place.

A press can't print a grey pixel. It puts down one colour of ink or it puts down nothing. So to reproduce a photograph it cheats, using a halftone. The Federal Agencies Digitization Guidelines Initiative defines it plainly: in a halftone, the continuous tones of the picture being reproduced are broken into a series of equally spaced dots of varying size, printed with only one colour of ink. Stand back and your eye blends the dots into tone. Put a loupe on a magazine page and you'll see them.

Which means a print job has three different numbers, and all three get called resolution by somebody.

• Your image, in PPI. How many pixels of picture data you handed over per inch of paper.
• The halftone screen, in LPI. Lines per inch, meaning how finely that grid of dots is ruled. This is the number your printer actually cares about.
• The output device, in DPI. Dots per inch, and it's far higher than either of the others, because the machine needs a cluster of tiny device dots to build each single variable-size halftone dot.

That's the honest answer to the question in this article's title. DPI and PPI aren't two names for one idea that people muddle. On a press they're two genuinely different measurements, separated by a third one in the middle.

And here's the satisfying part. FADGI puts the safe range for image resolution at 1.3 to 2 times the halftone screen, and gives the worked example: for the 150 lpi halftones typically used in magazine printing, the appropriate image file resolution runs from 195 ppi to 300 ppi.

Look at the top of that range. 150 lpi doubled is 300 ppi. The same number this guide already arrived at from the arcminute maths a few sections up, reached this time from ink and dot grids rather than from human eyes. Two completely unrelated constraints landing on one figure is why the 300 rule stuck around long after most people forgot either reason for it.

The National Archives shows the sum running in reverse. Its Guidelines for Digitizing Archival Materials for Electronic Access set photographic master files at 3,000 pixels across the long dimension, and justify it by noting that a magazine quality halftone reproduction at 11 by 14 inches and 133 lpi is achievable from that file size. Check it yourself. 3,000 pixels across 14 inches is roughly 214 ppi, against a 133 lpi screen. That's a ratio of about 1.6, sitting comfortably inside FADGI's band.

So the practical move is to stop guessing and ask. Get the line screen from whoever is printing the job, then multiply. Newspaper stock runs coarse because absorbent paper spreads ink, so it needs far less from you. Glossy magazine stock runs fine and needs more.

Which flips how you should think about 300. For a lot of jobs it's a ceiling rather than a floor. If your printer is running 133 lpi, sending 300 ppi buys you nothing at all beyond a bigger file.

Why Does Scanning a Printed Photo Look So Strange?

Because you're sampling a grid with another grid, and the two fight.

FADGI describes the mechanism directly. The spatial frequency of the halftone dot pattern and the spatial frequency applied by digital scanning and output devices interact, causing interference waves that show up as moiré patterns and degrade the image. Those are the odd rippling checkerboards you get when you scan something out of a book or a magazine.

This is the one place on this whole page where more resolution isn't automatically better, and can actively be worse. Everywhere else, adding pixels either helps or wastes storage. Here the damage depends on the relationship between two frequencies, not on the size of either one, so turning the scanner up can move you into a worse interference pattern rather than out of one.

FADGI sets out four ways round it.

• Reproduce in greyscale rather than trying to preserve the dot structure.
• Descreen and rescreen. Strip the halftone dots out, then generate a fresh screen if the image is going back to print. Most consumer scanner software has a descreen checkbox and it's usually the fastest fix.
• Capture bitonal at high resolution. This means going high enough to actually resolve the individual halftone dots, which takes a multiple of the original screen frequency.
• Randomise the scanner dot pattern. FADGI is careful here, noting this reduces moiré rather than eliminating it.

But the best fix is upstream of all four. Scan the original photograph if one exists, not a printed reproduction of it. A printed copy has already been through the halftone process once and thrown away the tones between the dots. You can't get those back, and no upscaler will invent them for you honestly, which is the same trap the AI upscaling section below gets into.

What Resolution Should Web Images Be?

Forget PPI entirely. Think in pixel widths and the layout slot the image has to fill.

• Blog body images: 1200 px wide covers most content columns with headroom.
• Full width hero banners: 1920 px, or 2400 px if you want it sharp on large dense displays.
• Thumbnails and cards: 400 to 600 px wide.
• Product photos with zoom: 2000 px on the long edge.
• Social posts: follow the platform spec, which our 2026 social media image sizes guide lists in full.

The rule of thumb is to serve roughly the width the image will occupy, not the width your camera produced. Uploading a 6000 px original into a 800 px slot means the browser downloads several megabytes and throws most of them away.

And that isn't a hypothetical failure mode. It's the normal one. The Web Almanac 2024 Media chapter found that 50 percent of mobile pages send images with more pixels than the mobile crawler can actually display. Half the web is shipping pixels nobody sees.

The Almanac also puts a number on what that costs when the sizing hints are wrong rather than absent. Among desktop pages using width descriptors, 20 percent load a suboptimal image because the sizes attribute misleads the browser. At the 75th percentile that wastes 179 KB on desktop and 55 KB on mobile. At the 90th percentile it's 920 KB on desktop and 400 KB on mobile. The report calls the trend troubling and notes the waste has almost doubled since 2022.

For scale, the median individual image on the web is about 12 KB. So a badly sized hero at the 90th percentile is burning the equivalent of roughly 75 ordinary images on one request, and it's getting worse rather than better. Picking the right pixel width is the cheapest performance work available to you.

Format choice matters as much as dimensions here. WebP and AVIF land far smaller than JPEG at the same visual quality, and the PNG vs JPG vs WebP comparison breaks down which to pick for which job.

Why Do Some Screens Want Images at 2x?

Because a CSS pixel and a hardware pixel stopped being the same thing.

Modern phones and laptops pack two or three physical pixels into the space of one CSS pixel. The layout still treats a 400 px wide slot as 400 px, but the panel has 800 or 1200 real pixels available to fill it. Feed it a 400 px image and the screen stretches each pixel across a 2 by 2 block, which reads as soft.

So for a display where things need to look crisp, supply the image at twice the CSS width. A 600 px slot gets a 1200 px file. This is exactly what the min-resolution: 2dppx media query is for, and since the W3C spec fixes 1dppx at 96dpi, a 2dppx screen is one running at an effective 192 dots per inch.

The obvious cost is weight. A 2x image carries four times the pixels, so compress it properly with our free image compressor or use srcset so browsers only fetch the version they need. There's more on the size and speed tradeoff in the website speed guide.

Which quietly undercuts the logo example you're about to read in the next section. Serving logo-200.png and logo-400.png is the correct answer if your logo is a raster file. It's the wrong question if it doesn't have to be one. Anything built from shapes and text rather than photographed, so logos, icons, charts and diagrams, is usually better off as SVG, and then the whole density conversation stops applying to it. Our format comparison covers when SVG is the right pick. Photographs are the genuine exception, since a photo has no shapes to describe and stays raster.

How Do You Serve the Right Resolution to Every Screen?

You don't pick one. You offer several and let the browser choose, which is the honest answer to "what resolution should this image be" once you accept that your visitors are on wildly different screens.

The section above left you with a real problem. A 2x image carries four times the pixels, so serving it to everyone punishes the person on an old laptop to please the person on a new phone. The srcset attribute exists to end that trade-off.

There are two ways to write it, and picking the right one saves a lot of confusion.

Density descriptors, for a fixed-size image. If your logo always renders 200 px wide, you just need a sharper copy for dense screens:

<img src="logo-200.png" srcset="logo-400.png 2x" alt="Logo">

Per MDN's reference on the img element, when you use x descriptors the src file is treated as the 1x candidate automatically. So low-density screens get the small one, dense screens get the big one, and you wrote one extra attribute.

Width descriptors, for an image that changes size with the layout. This is the one most content images need, and it takes two attributes:

<img src="photo-800.jpg" srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1600.jpg 1600w" sizes="(max-width: 600px) 100vw, 800px" alt="Photo">

The w values state how wide each file actually is in pixels. The sizes attribute tells the browser how wide the image will be displayed, which it can't work out on its own before layout happens. It divides one by the other, factors in the device pixel ratio, and downloads the single best match.

Of the two syntaxes, the second is the one the web actually reaches for. In the sites that use srcset at all, w descriptors appear in 62 percent of mobile cases and 64 percent on desktop. So most developers are solving the layout-dependent problem rather than the fixed-logo one, which matches where the real difficulty sits. If you're unsure which you need, the majority answer is width descriptors plus sizes.

Worth knowing how few sites do this at all. The 2024 Web Almanac from HTTP Archive parsed over 10 million pages and found srcset on just 42 percent of mobile pages. That's real progress from 34 percent in 2022, but it still means most of the web ships one image to every device. The <picture> element, which you need for swapping formats or art direction rather than just size, sat at 9.3 percent. Native lazy loading reached 33 percent, up from roughly 25 percent in 2022.

One note on the vintage of those numbers, since 2024 sounds dated for a web statistic. It's the most recent set there is. The Web Almanac's 2025 edition ran to sixteen chapters and didn't include a media chapter at all, so nobody has re-measured this since. Treat the figures as current rather than lagging.

And the pressure is going the wrong way. The same report found the 90th percentile largest image grew 13 percent to nearly 1 MB. Images are getting heavier faster than sites are getting smarter about serving them.

One limit worth stating plainly, because responsive markup gets oversold. Offering three sizes of a badly prepared image just gives the browser three bad choices. Resize and compress properly first, then let srcset decide which of your good files to send. Our image resizer and compressor both run in your browser, so you can produce the set without uploading anything.

What Happens to Your Image When Someone Zooms In?

It gets spent. Every section above is about you choosing a pixel budget. Zoom is the case where somebody else decides how much of that budget to use, and if you picked for a 1x layout you've already run out.

This isn't an edge case. People magnify pages because they need to, and the accessibility standard treats it as a requirement rather than a preference.

W3C's Success Criterion 1.4.4 Resize Text, a Level AA requirement, says text must be resizable "without assistive technology up to 200 percent without loss of content or functionality." Note the carve-out at the front of that sentence though: it reads "except for captions and images of text."

So images of text are exempt. Which sounds like a let-off until you read why W3C put them there. The same document says images of text "do not scale as well as text because they tend to pixelate, and therefore we suggest using text wherever possible." They're not exempt because they're fine. They're exempt because they can't comply.

There's a second criterion pointing the same way. 1.4.10 Reflow, also Level AA, requires content to work "without requiring scrolling in two dimensions" at a width equivalent to 320 CSS pixels, or a height of 256 CSS pixels for horizontally scrolling content. It does carve out content that genuinely needs a two-dimensional layout, and the examples it gives include images required for understanding, such as maps and diagrams.

Read those together and you get a clean rule. A diagram someone has to pan around is anticipated by the spec. A paragraph you saved as a JPEG is not.

Why Text in an Image Is the Expensive Mistake

W3C is direct about it in Success Criterion 1.4.5 Images of Text, another Level AA item: where the technology can achieve the visual presentation, use text rather than an image of text, with narrow exceptions for customisable and essential cases.

The reason it gives is the one that matters for a resolution guide: "People cannot alter how text looks in images." Someone who needs a larger size, a different typeface or higher contrast can do all of that to real text and none of it to your PNG. Their only remaining move is to zoom, which is exactly the operation your raster file is worst at.

And this is where the earlier sections come back. Real text is resolution-independent in the same way the vector logos further up this page are. It re-renders crisply at any size because the browser is drawing it, not enlarging a grid.

What to Actually Do

• Stop shipping text as pixels. Quote cards, infographic captions, pricing tables, screenshots of paragraphs. If it's a sentence someone needs to read, it should be text in the page.
• Give real diagrams room to be zoomed. Where a picture genuinely has to be a picture, supply enough pixels that panning into it still resolves. This is the one place generous dimensions are the accessible choice rather than the wasteful one.
• Test at 200 percent and at 320 CSS pixels wide. Both are in the standard, both take a minute in your browser, and both surface the same failures. Zoom to 200 and narrow the window.
• Use SVG for anything diagrammatic. Charts, flows, labelled figures. It scales without a ceiling and the labels stay sharp, which no raster export manages.
• Write real alt text either way. The pixel count does nothing for someone using a screen reader. That's a separate obligation and it isn't optional.

The through-line with the rest of this page is worth naming. Most resolution decisions are about not wasting bytes. This one runs the other direction: it's the case where being stingy with pixels, or reaching for an image when text would do, makes your page unusable for somebody rather than merely soft.

Can You Increase the Resolution of an Image?

You can make the pixel count bigger. You cannot invent detail that was never captured.

Upscaling works by interpolation. The software looks at the pixels it has and guesses what should sit between them. Older methods like bicubic average their neighbours, which is why enlarged images go soft and edges pick up a slight halo. AI upscalers guess with far more context and produce results that often look genuinely good, but they're still generating plausible detail rather than recovering the real thing. On text, faces and fine patterns that difference shows.

NARA makes a related point about capture itself: "simply increasing the sampling rate or size doesn't necessarily result in better quality if the scanner cannot meet the specifications." True optical resolution depends on what the hardware can actually resolve, which is why the federal guidelines call for verification against ISO compliant test targets rather than trusting the number in the settings dialog. Turning a scanner up to 1200 PPI when its optics top out lower gets you a bigger file, not a better one.

The practical advice is boring and effective. Find the largest original you have before you upscale anything. The version someone sent you over WhatsApp is already compressed and shrunk, and no amount of enlarging brings back what that trip removed.

When Can You Trust an AI Upscale?

Trust it for texture. Don't trust it for facts.

That one line does most of the work, but it's worth seeing where it comes from, because the reason isn't that today's models are still immature. It's structural. A better model next year doesn't fix it.

Start with what the research field calls this job. In the peer reviewed literature, upscaling a face has a name, and the name is face hallucination. That's the term used in the PULSE paper presented at CVPR 2020 by Sachit Menon, Alexandru Damian, Shijia Hu, Nikhil Ravi and Cynthia Rudin. The people building these systems chose that word themselves, and they weren't being modest about it.

Read what PULSE actually optimises for and you can see why. The paper describes traversing "the high-resolution natural image manifold, searching for images that downscale to the original LR image." The test it sets itself is right there in the abstract. The output has to "downscale correctly." Not match the person in the photo. Downscale correctly.

Those two things are not the same, and the gap between them is the entire problem. A huge number of different high resolution faces all shrink down to the same small blurry patch. Whatever separated them got thrown away when the image was made small, and nothing left in the file records which one it was. So the algorithm returns a face that's consistent with the blur and looks convincing. It can't return the right one, because the file no longer contains the answer. It isn't reading detail out of your image. It's writing detail into it.

The PULSE authors were straight about where that leads. Their abstract promises "a discussion of the limitations and biases of the method as currently implemented with an accompanying model card." That caution earned its keep almost immediately. When a tool built on the same approach reached the public and people fed it pixelated photos of well known Black and Asian faces, it handed back white ones. It wasn't recovering anybody. It was generating whoever the training data made most likely.

What Happens When the Stakes Are Higher Than a Blog Photo

The same failure has been studied where it can actually hurt someone. In On hallucinations in tomographic image reconstruction, published in IEEE Transactions on Medical Imaging in 2021, Sayantan Bhadra, Varun A. Kelkar, Frank J. Brooks and Mark A. Anastasio put it plainly: "An inaccurate prior might lead to false structures being hallucinated in the reconstructed image and that is a cause for serious concern in medical imaging."

Their work was serious enough that they had to invent a way to measure it. Speaking to the University of Illinois bioengineering department, co-first author Varun Kelkar described the range: "A hallucination could be something minor, such as a slight imperfection at the boundary of a tissue, or it could be something major, like introducing an entire fold of tissue in the brain." Co-author Sayantan Bhadra named the consequence: "That makes it hard to tell when a medical abnormality might actually be a false structure created by the machine-learning method."

Kelkar also explained what they were separating out. The goal was "to separate sources of systemic error, like measurement errors or noise, from errors that arise due to inaccurate assumptions about the to-be-imaged subject." That's a useful distinction to carry back to your own files. Noise looks like damage. A hallucination looks like detail.

So Where Does That Leave Your Actual Images?

Somewhere quite comfortable, as long as you sort your images by whether anyone reads a fact off them.

• Fine to upscale. Foliage, fabric, stonework, sky, blurred backgrounds, general photographic texture. Nobody verifies a leaf. If the invented detail is plausible, it has done its job.
• Check it carefully. Faces you only need to look right rather than be identifiable, patterned surfaces, anything where a viewer might notice a repeat that shouldn't be there.
• Don't upscale. Text of any kind, logos, charts, part numbers, serial numbers, prices, measurements on a diagram. These are the cases where a confident wrong pixel becomes a confident wrong fact, and they're exactly the content the section on text in images already warns you to keep out of raster files.
• Never. Anything that will be evidence, a medical image, or a record somebody relies on. Keep the original untouched.

There's a print trap in here too. Upscale a small file and you can genuinely hit 300 PPI at A4, because PPI only counts pixels per inch and upscaling produces real pixels. The number will pass any check you run. It just won't look right in the hand, because the pixels are inference rather than record. Meeting the number and meeting the standard are different things, which is the same lesson the scanner specifications teach from the other direction.

One test costs nothing. Shrink your upscaled version back down to the size of the original and compare the two. Any detail that appears in the big one but has no ancestor in the small one was invented. And the boring advice from the section above still beats every model on the market. Go and find the largest original you have, and run it through the image size checker before you decide you need to upscale at all. More often than you'd expect, the file you needed was already sitting somewhere.

Is Pixel Count the Only Kind of Resolution?

No, and the other kind explains a failure that more pixels will never fix. If you have ever exported a smooth sky or a soft gradient and watched it come out in visible stripes, you met it already.

Everything above this point is about spatial resolution: how many pixels, spread over how much space. Bit depth is the other axis. It is not how many pixels you have, but how many different values each one is allowed to hold.

The W3C PNG specification is unusually plain about the arithmetic. It allows bit depths of 1, 2, 4, 8 and 16, and the maximum sample value for any of them is 2 to the power of the bit depth, minus one. So a channel gets:

• 8-bit: values 0 to 255, which is 256 steps per channel.
• 16-bit: values 0 to 65535, which is 65,536 steps per channel.

That 256 sounds like plenty until you spread it across something wide and smooth. A sunset gradient running from deep orange to pale yellow across 3000 pixels has to pick from 256 available steps. Do the division and each step has to cover roughly twelve pixels. Where the gradient changes slowly, those steps become visible edges. That is banding, and it is the fingerprint of running out of tonal resolution rather than spatial resolution.

Which is the practical reason to care. Bit depth is decided at capture and at export, and once it is gone you cannot get it back by resizing, the same way you cannot get spatial detail back by upscaling. Both are one-way doors, and the upscaling section above applies here in spirit.

So where does this actually bite?

• Editing, not delivering. If you are going to push exposure or colour hard, working in 16-bit gives the maths room to move before rounding shows up. Export to 8-bit at the end.
• Big smooth areas. Skies, studio backdrops, soft shadows, anything with a slow gradient across a lot of pixels. Detailed textures hide banding; flat areas advertise it.
• Screenshots of gradients. A common surprise. The screenshot is 8-bit by definition, so a gradient that looked fine in your editor can band the moment you capture it.

And where it genuinely does not matter. Most photographs delivered on the web are 8-bit and always have been, and they look correct because real scenes have enough texture and noise to break the steps up. This is not a reason to start exporting everything at 16-bit. The files are roughly twice the size and browsers will not show you the extra values anyway.

The useful takeaway is smaller than the section. When an image looks wrong, work out which kind of resolution is missing before you reach for a fix. Blurry or soft means you are short of pixels. Striped or stepped in the smooth parts means you are short of values. Those are different problems, and the fix for one does nothing for the other.

Do More Megapixels Mean a Better Image?

Up to a point, then no. And the point where it stops arrives earlier than the marketing suggests.

This is the same argument as the section above, pointed at the camera instead of the scanner. NARA's line about scanners applies just as cleanly here: turning the number up doesn't help if the optics can't resolve that much detail. A camera has optics too, and they have a hard physical ceiling.

Light doesn't travel through an aperture and land as a point. It spreads, and a single point in the scene arrives on the sensor as a small bright disc with faint rings around it, called the Airy disk. That's not a lens flaw. It happens in every optical system ever built, including your eye.

Physics puts a number on it. The Rayleigh criterion, as Harvard's natural sciences demonstrations set it out, says two points are only just distinguishable when the centre of one Airy disk falls on the first dark ring of the other. For a circular aperture the minimum angular separation is θ = 1.22λ/D, where λ is the wavelength of light and D is the aperture diameter. The University of Central Florida's open College Physics text works through the same result.

Read what's in that formula, and more importantly what isn't. Wavelength and aperture. Not pixel count. The lens decides the finest detail that can arrive at the sensor at all, and no sensor can record detail the lens never delivered.

So here's the sequence that catches people out. Sensor size mostly stays put, especially in phones. Push the megapixel count up and each pixel gets smaller. That works, and finer pixels do capture finer detail, right up until the pixels become smaller than the blur landing on them. Past that, one point of light smears across several pixels, and the extra pixels are recording the same soft patch in more slices. Bigger file. Same detail.

The phone makers already know this, and their own behaviour is the giveaway. Buy a 48 or 200 megapixel phone and it will almost certainly hand you a 12 megapixel photo unless you dig into settings and change the mode. That's pixel binning: the sensor combines a block of neighbouring pixels, typically 2 by 2 or 3 by 3, into one output pixel, trading the headline resolution for a cleaner, less noisy image. You can check this on your own phone in about ten seconds by looking at the dimensions of a photo you took today.

Which is worth sitting with. The number on the box is a number the manufacturer chooses not to use by default.

None of this means megapixels are meaningless. They set the ceiling on how much you can crop and how large you can print, which is what most of this guide is about. A 12 megapixel file is 4000 by 3000, comfortably enough for a 13 by 10 inch print at 300 PPI. It's just that beyond a sensible point, extra megapixels buy you cropping room rather than a sharper image, and they cost you storage, upload time and processing on every single photo.

The practical version, which lines up with everything else here:

• Work backwards from the output, the same as for print and web. Decide the largest print or crop you actually need, then check whether your camera clears it. Most people's honest answer is that 12 megapixels already does.
• Judge a camera by its photos, not its spec. Lens quality, sensor size and processing move the result far more than the pixel count once you're past a modest threshold.
• Leave your phone in its default mode unless you have a specific reason to want the full-resolution file. The binned image is usually the better photograph, which is why it's the default.

Which Resolution Mistakes Cost People the Most?

Four keep showing up.

Setting DPI instead of pixels for web work. Changing a file from 72 to 300 DPI in an export dialog does nothing to how it appears in a browser. Change the pixel dimensions instead.

Sending a screen sized image to print. A 1200 px wide file at 300 PPI covers 4 inches. Ask a printer for A4 from it and you get visible softness across the page.

Cropping first, then discovering you're short. Cropping throws pixels away permanently. If you plan to print, crop conservatively and check the remaining dimensions against your target before you commit. The image cropping guide covers this in more detail.

Resizing the same file repeatedly. Every JPEG save runs lossy compression again on whatever survived the last one. Keep one high resolution master and export copies from it rather than editing the export.

What Else Do People Ask?

Is 72 DPI the correct resolution for web images?

No. 72 DPI is a leftover from early Macintosh displays and it has no effect on how a browser renders your picture. The CSS specification fixes one inch at exactly 96 pixels, so browsers ignore the DPI value stored in the file completely. Set the pixel width and height you actually want and leave the DPI field alone.

What is the difference between DPI and PPI?

DPI counts the dots of ink a printer can lay down across one inch of paper. PPI counts pixels, either packed into one inch of a print or into one inch of a screen. The US National Archives describes them as entirely different measures that people now use interchangeably. Printers deal in DPI. Files and screens deal in PPI.

What resolution do I need to print a photo?

Multiply the print size in inches by 300 PPI. A 4 by 6 inch print needs 1200 by 1800 pixels, and an 8 by 10 needs 2400 by 3000. US federal digitisation rules set 300 PPI as the floor for modern paper records and 400 PPI for photographic prints. Big posters viewed from further away can drop to 150 PPI.

Can you increase the resolution of an image?

You can enlarge the pixel count, but you cannot recover detail that was never captured. Upscaling invents new pixels by guessing from the ones around them, which softens edges and smears fine texture. AI upscalers guess more convincingly than older methods, though they are still guessing. Always go back to the largest original file you have first.

How do I check the resolution of an image?

Right click the file and open its properties or info panel, where the pixel width and height are listed. On the web you can drop the file into a browser based checker that reads the dimensions on your own device without uploading anything. The number that matters is the pixel count, not whatever DPI value the file happens to carry.

Sources: W3C Web Accessibility Initiative, Understanding Success Criterion 1.4.4 Resize Text (Level AA), for the 200 percent resize requirement, the exception for captions and images of text, and the statement that images of text do not scale as well as text because they tend to pixelate. W3C Web Accessibility Initiative, Understanding Success Criterion 1.4.10 Reflow (Level AA), for the 320 CSS pixel width and 256 CSS pixel height thresholds and the exception for content requiring two-dimensional layout such as maps and diagrams. W3C Web Accessibility Initiative, Understanding Success Criterion 1.4.5 Images of Text (Level AA), for the requirement to use text rather than images of text where the technology allows, the customisable and essential exceptions, and the statement that people cannot alter how text looks in images. W3C, CSS Values and Units Module Level 4, absolute length units, the reference pixel, and resolution units including dppx (w3.org/TR/css-values-4). US National Archives and Records Administration, Records Express, "When We Say We Want Resolution: DPI and PPI Explained", 22 August 2023, and "Digitizing Records: Requirements for Paper and Photographs", 7 June 2023, covering 36 CFR §1236.50 (archives.gov). HTTP Archive, Web Almanac 2024, Media chapter, based on more than 10 million parsed pages, for the 42 percent srcset adoption on mobile against 34 percent in 2022, the 9.3 percent picture element figure, the 33 percent native lazy loading figure, the 62 percent of mobile and 64 percent of desktop srcsets using w descriptors, the 13 percent growth in the 90th percentile largest image to 1,002 KB, the 50 percent of mobile pages sent more pixels than the crawler can display, the 20 percent of desktop pages with inaccurate sizes hints, the 179 KB and 920 KB desktop waste figures at the 75th and 90th percentiles, and the 12 KB median image weight. The 2024 edition is the latest media data available, since the 2025 Web Almanac ran to sixteen chapters without a media chapter. Mozilla Developer Network, the img element reference, for how the w and x descriptors and the sizes attribute drive candidate selection, and for src acting as the 1x candidate. Federal Agencies Digital Guidelines Initiative, Technical Guidelines for Digitizing Cultural Heritage Materials, third edition approved 9 May 2023 (digitizationguidelines.gov). W3C, About SVG, for resolution independence and the statement that SVG provides identical online and hardcopy display; SVG 1.1 and the SVG Mobile Profiles are W3C Recommendations. Kalloniatis, M. and Luu, C., "Visual Acuity," in Webvision: The Organization of the Retina and Visual System, University of Utah Health Sciences Center, hosted on the NIH National Library of Medicine NCBI Bookshelf, for the one arcminute minimum angle of resolution. Ashraf, M., Chapiro, A. and Mantiuk, R.K. (2025), "Resolution limit of the eye, how many pixels can we see?", Nature Communications, PMC12559231, for the 94, 89 and 53 pixels per degree measurements against the 60 ppd standard. Harvard University Natural Sciences Lecture Demonstrations, Rayleigh's Criterion, and the University of Central Florida open edition of College Physics, section 27.6 Limits of Resolution: The Rayleigh Criterion, for the Airy disk and the minimum resolvable angular separation of θ = 1.22λ/D for a circular aperture. Pixel binning is described as the default behaviour of current high-megapixel phone sensors, which is checkable against the dimensions of a photo from your own device, rather than as a claim about any specific manufacturer's implementation. W3C, PNG Specification (Third Edition), W3C Recommendation 24 June 2025, for the pHYs chunk fields (pixels per unit X axis, pixels per unit Y axis, unit specifier), the unit specifier values 0 for unknown and 1 for the metre, and the status of pHYs as an ancillary chunk that decoders may ignore. The 299.9994 PPI figure follows arithmetically from storing 300 PPI as a whole number of pixels per metre (300 / 0.0254 = 11,811.02, stored as 11,811). JPEG File Interchange Format, version 1.02, 1 September 1992, hosted by the W3C, for the APP0 marker segment units byte and its values 0 for no units, 1 for dots per inch and 2 for dots per cm, and for the two-byte Xdensity and Ydensity fields. Later formalised as ITU-T Recommendation T.871, also published as ISO/IEC 10918-5, approved May 2011. JEITA CP-3451C and CIPA DC-008-2012, Exchangeable image file format for digital still cameras: Exif Version 2.3, page 37, for XResolution (tag 282, default 72), YResolution (tag 283, default 72) and ResolutionUnit (tag 296, default 2, where 2 is inches and 3 is centimetres), and for the instructions that 72 dpi shall be designated when the image resolution is unknown and that 2 (inches) shall be designated if the resolution is unknown. Federal requirements apply to US agency records and are cited here as a published quality benchmark, not as a rule for personal printing.

Know the pixels you need? Our free image resizer and image size checker both run in your browser, so nothing gets uploaded anywhere.

📐 Resize an Image Free →

Read next: Image Formats: The Complete Guide · How to Resize an Image · Best Image Format for a Website