Do Web Images Have to Be 72 DPI? The Real Rules of Image Optimization

No. Web images do not have to be 72 DPI. The DPI field in your export settings has no effect on how an image looks in a browser, because browsers only read pixel dimensions and file size. Image optimization for the web comes down to those two numbers and the format you save in.

That answer is easy. I've given it to a dozen business owners, and every one of them nodded, went back to their site, and still had a homepage that took six seconds to load on a phone.

So the DPI question isn't really the interesting one. The interesting one is why websites stay heavy long after somebody learns the right answer. We'll get there, because that's the part costing you leads.

What Does DPI Actually Mean, and Why Doesn't It Apply to Screens?

DPI stands for dots per inch, and it's a printing instruction. It tells a printer how densely to lay ink on a piece of paper. It has nothing to say about a screen, and a browser ignores it completely.

Resolution is a word that gets thrown around a lot in design work, and it's hiding two completely different ideas under one label. In print, resolution means ink density, and that's DPI. On screens, it means pixel density, and that's PPI, which is a property of the monitor you bought, not of the file you exported. Your image file has exactly one thing a browser cares about: how many pixels wide and tall it is.

Try it yourself. Open any photo in Photoshop, turn resampling off, and change the DPI from 72 to 300. Now look at the file size. Notice what happened: nothing. Not one kilobyte moved, because you changed a label, not an image.

Where Did the 72 DPI Rule Come From in the First Place?

The rule is a leftover from early Macintosh screens, which displayed roughly 72 pixels per inch. That number happened to match the typographic point system, where there are 72 points to an inch, so a designer could hold a printed page next to the monitor and see the same thing twice.

It was a convenience, not a standard. But convenience became default, default became habit, and habit became a rule people still repeat in 2026.

That was 1984. The phone in your pocket is somewhere north of 400 pixels per inch, and a decent laptop screen isn't far behind. The number stopped describing reality about thirty years ago, and it's still sitting in the export dialog making designers feel like they did something.

What Size Should You Actually Export Web Images At?

Export at the pixel dimensions the image will actually display at, then serve a 2x version to high-density screens. A photo filling a 600 pixel wide column needs a 600 pixel file for standard screens and a 1200 pixel file for Retina. It does not need one 3000 pixel file sent to everybody.

That's what the srcset attribute and the picture element exist for. You give the browser a few sizes, the browser picks the right one for the device in front of it, and a phone stops downloading a desktop hero it will never show at full width.

Webflow handles the responsive versions for you on image elements, which is one of the less obvious reasons I build most client sites there. On a custom build you have to write the markup yourself, or use a framework that does it at build time.

Don't get me wrong, one oversized hero image will not sink your website. Forty of them will.

Which Image Format Should You Use in 2026?

Use AVIF or WebP for photographs, and SVG for anything that's a logo, an icon, or line art. JPEG and PNG are fallbacks now, not defaults. Here's how I'd pick:

• AVIF: the smallest files at a given quality, often around half the weight of the same JPEG. Slower to encode and best on modern browsers, which is now most of them.
• WebP: the safe default. Universally supported, comfortably lighter than JPEG and PNG, and fast to generate in bulk.
• SVG: logos, icons, and simple illustrations. It's math instead of pixels, so it stays sharp at any pixel density with no extra file weight. This is where the whole DPI conversation stops mattering entirely.
• JPEG and PNG: keep them as fallbacks. Reach for PNG only when you need lossless transparency and SVG won't do the job.

If you want the step-by-step on the conversion itself, I wrote a separate walkthrough on shrinking image size and converting to AVIF.

So Why Is Your Website Still Heavy If the Rules Are This Simple?

Because nobody owns image weight. Not the designer, not the developer, not the person adding blog posts on Thursday afternoons. Everyone assumes it got handled at launch, and after launch it stops being anyone's job.

I've watched this happen for years, and it always goes the same way. A site launches clean and fast. Then someone adds a team photo straight off a phone. Then a case study with eight screenshots. Then a new hire uploads the logo as a four megabyte PNG, because that was the file sitting in the shared drive. A little heavier turns into a lot heavier. Eighteen months later the homepage is four megabytes on mobile, and nobody can point to the day it happened.

Nobody owns it at launch, because the designer assumes the developer will compress the exports. Nobody owns it at handoff, because the developer assumes the CMS will handle it. Nobody owns it in month six, because the person adding content was never told there was a rule. Nobody owns it at all, and the site gets a little slower every quarter until somebody finally asks why the phone number page takes four seconds to appear.

I believe image weight is an ownership problem wearing a technical costume. The technical part got solved years ago. Anyone can drag a file into a compressor and get 70% of the weight back in a minute. What almost no growing business has is one person whose actual job it is to care whether that happened.

Now, I don't think this means you need a performance engineer on payroll or a monthly audit retainer. You need a name and a number. That's the whole fix.

Want to see what this is costing you today? Run your homepage through PageSpeed Insights and look at the total image payload. Anything over a megabyte is worth an hour of your week. Our free Asset Optimizer will claw most of it back in about ten minutes, and nothing you drop into it ever leaves your browser.

How Do You Give Someone Ownership of Image Weight?

Pick one person, one number, and one recurring check. Three decisions, none of them technical, and they hold the whole thing together.

Think about it this way. Nobody builds a house without gutters, and nobody's gutters fail on install day. They fail four autumns later, when the leaves have piled up and nobody's been up the ladder since the contractor left. Your website's images work the same way. The build was fine. The maintenance never got assigned.

• One person: whoever adds content most often. Not your web guy, who touches the site twice a year. The person uploading the photos is the person who needs the rule.
• One number: a maximum file size for anything that goes on the site. I use 200KB for standard content images and 400KB for full-width heroes. Write it down somewhere the whole team can see it.
• One check: once a quarter, run your homepage and your two best-performing pages through PageSpeed Insights. Fifteen minutes, four times a year. That's the entire maintenance program.

A rule nobody wrote down isn't a rule, it's a preference. And preferences don't survive a busy quarter.

What Tools Should You Use to Compress Images for the Web?

Any tool that converts to WebP or AVIF and lets you cap the largest dimension will do the job. The one that matters is the one your team will actually open, which usually means no account, no upload, and no subscription.

• CL Creative Asset Optimizer: our free tool. Bulk convert to WebP and AVIF, resize or crop, and compress video too. Everything runs in your browser, so client photos and unreleased product shots never touch a server.
• Squoosh: best for one image at a time when you want to eyeball the quality slider and see exactly where the image starts to fall apart.
• The terminal: for a few hundred files at once, a one-line command beats any interface. I wrote up the exact commands if you want them.

Let me just be real for a minute about why we built our own. I got tired of telling clients to use a compressor that ships their unreleased product photos off to somebody else's server without making a big deal about it. So we made one that doesn't, and gave it away.

The DPI Field Was Never the Problem

You can learn everything in this post in ten minutes. Pixel dimensions over DPI. AVIF or WebP over JPEG. Responsive sizes over one giant file. None of it is hard, and none of it will hold if the knowledge lives in your head and nowhere in your process.

Your images are either being watched by someone or they're getting heavier. There isn't a third option. So who owns image weight on your website right now?

Want someone to own it with you?

Book a free 30-minute strategy call. We'll pull up your site, tell you what your images are actually costing you in load time, and leave you with the file-size rule and the ownership plan that keeps it from creeping back, whether you hire us or not. Book a strategy call.

Want to start on your own this afternoon? Drop the images from your three heaviest pages into the free Asset Optimizer. Bulk conversion to WebP and AVIF, dimension caps on oversized files, video compression, and every bit of it processed on your own device.