11 Image Optimization Myths That Refuse to Die

Image advice ages badly. A rule that was correct in 2014 gets repeated in a blog post in 2018, quoted in a Stack Overflow answer in 2021, and is still being applied in 2026 to a browser landscape that changed completely underneath it.

These eleven are the ones that still cause real damage. Each entry says what people believe, what is actually true, and how to check for yourself.

1. “Export at 300 DPI So It Looks Sharp on the Web”

Status: never was true.

DPI, or more accurately PPI, is a number in the file’s metadata that tells a printer how large to print the image. Browsers ignore it completely.

# These two files are byte-different but display identically in every browser
magick photo.jpg -density 72 out-72.jpg
magick photo.jpg -density 300 out-300.jpg

# Same pixel dimensions, which is the only thing that matters
magick identify -format "%f: %wx%h at %x DPI\n" out-72.jpg out-300.jpg

What Actually Controls Sharpness

Pixel dimensions relative to the CSS display size and the device pixel ratio. An image displayed 400 CSS pixels wide on a 2× screen needs 800 real pixels. The DPI field is irrelevant to that calculation.

Why It Persists

Print designers moved to web work and brought the habit with them. It is harmless in itself, which is exactly why nobody corrects it. The damage comes indirectly: “300 DPI” usually arrives with an image four times larger than needed.

2. “WebP and AVIF Are Not Widely Supported Yet”

Status: was true, stopped being true years ago.

Format	Chrome	Firefox	Safari	Edge
WebP	2014 (v32)	2019 (v65)	2020 (v14)	2018 (v18)
AVIF	2020 (v85)	2021 (v93)	2022 (v16)	2020 (v85)

Both are supported by every browser a normal site needs to care about. WebP has been universal since 2021, AVIF since 2022.

The Real Blocker

Nobody who repeats this myth has checked recently. The genuine obstacle is not support, it is that generating and serving multiple formats requires either <picture> markup in every template or a CDN that negotiates per request. That is a workflow problem being mistaken for a compatibility problem.

<!-- The fallback costs almost nothing and removes the argument entirely -->
<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" width="1200" height="800" alt="…">
</picture>

Browsers that do not understand a type simply skip that <source>. There is no risk.

The One Format Where the Myth Is Still True

JPEG XL. Safari 17+ enables it by default. Chrome removed it in version 110, then re-added it in version 145 (February 2026) behind the enable-jxl-image-format flag, and Firefox 152 followed in June 2026 behind image.jxl.enabled. So every engine now has a decoder, but only Safari ships it on, and a flag nobody turns on delivers no traffic. For JXL, “not widely supported” is still accurate today. See the JPEG XL guide.

3. “Lazy Load Every Image”

Status: half true, and the wrong half is expensive.

Lazy loading below-fold images is correct. Lazy loading the hero image is one of the most costly single attributes you can add to a page.

Why the Hero Case Is So Bad

A lazy image is not fetched until layout runs and the browser confirms it is in the viewport. That inserts a full round trip into the critical path, after the preload scanner has already been told to ignore it. LCP regressions of 500 ms to 1,500 ms from this alone are routine.

The Correct Rule

Position	loading	fetchpriority
LCP / hero	omit, or eager	high
Above fold, not LCP	omit	omit
Below fold	lazy	omit
Decorative, below fold	lazy	low

Check Your Own Page

new PerformanceObserver(list => {
  const lcp = list.getEntries().at(-1);
  console.log('LCP element:', lcp.element);
  console.log('loading:', lcp.element?.getAttribute('loading') ?? '(none)');
}).observe({ type: 'largest-contentful-paint', buffered: true });

If that prints lazy, the myth is costing you right now. The lazy loading guide covers the threshold rules.

4. “PNG Is Higher Quality Than JPEG”

Status: true in a way that misleads.

PNG is lossless, so in the strict sense it preserves the original pixels exactly and JPEG does not. That fact then gets applied to photographs, where it produces a file five to ten times larger for a difference nobody can see.

Content	PNG	JPEG q85	Visible difference
Photograph, 1600×1067	2,840 KB	195 KB	None at display size
Screenshot with text	620 KB	380 KB	JPEG shows fringing on text
Flat illustration	180 KB	240 KB	JPEG shows ringing on edges
Logo with hard edges	24 KB	68 KB	JPEG is visibly worse

The Actual Rule

Lossless is right when the pixels carry structure: text, hard edges, flat colour, screenshots. Lossy is right when the pixels carry continuous tone: photographs. “Higher quality” is not a property of the format, it is a property of the match between format and content.

For a photograph that also needs transparency, the answer is WebP or AVIF, both of which have full alpha channels and are far smaller than PNG. See the PNG guide.

5. “Quality 100 Means Lossless”

Status: false, and expensive.

In JPEG, quality 100 still applies the discrete cosine transform, still quantizes, and still subsamples chroma unless you turn that off separately. It is lossy compression with the quantization dialled almost to nothing.

Setting	Size	Actually lossless?
JPEG quality 100	640 KB	No
JPEG quality 85	195 KB	No
WebP quality 100	410 KB	No
WebP -lossless	890 KB	Yes
AVIF --lossless	760 KB	Yes
PNG	2,840 KB	Yes

Notice that true lossless WebP is larger than lossy WebP at quality 100. They are different modes, not different points on one scale.

What to Do Instead

If you want lossless, ask for lossless explicitly:

cwebp -lossless -z 9 in.png -o out.webp
avifenc --lossless in.png out.avif

If you want a photograph to look right at a sensible size, use 80 to 85 in JPEG, 75 to 82 in WebP, or 55 to 63 in AVIF. Quality 100 gives you two to three times the bytes for a difference you cannot see. See the export settings guide.

6. “Compression Always Visibly Degrades the Image”

Status: false at the settings anyone should be using.

This belief comes from real experience: someone once saved a JPEG at quality 40, watched it fall apart, and concluded that compression is a quality tax. At sensible settings there is a wide band where file size drops steeply and nothing visible changes.

Find the Knee Yourself

#!/usr/bin/env bash
for q in 95 90 85 80 75 70 65 60; do
  cwebp -quiet -q $q input.jpg -o "/tmp/test-$q.webp"
  printf "q%-3s %6s KB\n" "$q" "$(( $(stat -c%s "/tmp/test-$q.webp") / 1024 ))"
done

Open the outputs at display size, not zoomed to 400%. The point where you first see a difference is usually far below where most people set their exports.

The Grain of Truth

Generation loss is real. Re-saving a JPEG repeatedly does degrade it, because each save quantizes an already-quantized image. Keep a lossless master and derive from it every time, rather than editing and re-saving deliverables. The compression fundamentals guide explains what is actually discarded.

7. “Fewer Images Means a Faster Page”

Status: confuses count with weight.

Over HTTP/2 and HTTP/3, requests are multiplexed over one connection. The per-request overhead that made image sprites essential in 2010 is largely gone. Twenty well-optimized 30 KB images load faster than three 400 KB ones.

Page	Images	Total bytes	Typical LCP
A	3	1,200 KB	Slower
B	20	600 KB	Faster

What Actually Matters

1. The weight of the LCP image specifically
2. Total bytes, not total requests
3. Whether below-fold images are deferred
4. Priority: is the browser fetching the important one first?

Where the Myth Still Applies

If your images are served from an origin with no HTTP/2, or each image sits on a different hostname requiring separate connection setup, request count still costs you. Both are worth fixing directly rather than by reducing the number of images.

Sprite sheets are now mostly counterproductive: they force you to download every icon to show one, they cannot be cached granularly, and SVG icons solve the problem better.

8. “SVG Is Always Smaller”

Status: true for what SVG is for, false in general.

SVG stores instructions rather than pixels, so a logo is 3 KB instead of 200 KB. But the file size scales with the complexity of the drawing, not with the display size.

Asset	SVG	PNG	Winner
Simple logo	3 KB	24 KB	SVG
Icon set, 40 icons	18 KB	160 KB	SVG
Detailed map with 3,000 paths	890 KB	180 KB	PNG
Auto-traced photograph	4,200 KB	210 KB	PNG, heavily
Chart with 12 data points	6 KB	45 KB	SVG

An SVG produced by auto-tracing a photograph is the worst of all worlds: enormous, slow to render, and worse looking than the original.

The Rule

If the asset was drawn, use SVG. If it was photographed, do not. And always run SVGO, which strips 40% to 70% from a typical design tool export:

npx svgo --multipass --disable=removeViewBox icon.svg -o icon.min.svg

Disable removeViewBox. SVGO removes it by default, which breaks fluid scaling. See the SVG guide.

9. “Alt Text Is an SEO Field”

Status: backwards, and it produces bad alt text.

Alt text exists so that people who cannot see the image get its content. Search engines read it as a side effect, because it is the best available description. Treating it as a keyword slot produces text that is worse for both.

<!-- Written for a crawler: painful to hear, discounted by search engines anyway -->
<img src="lamp.jpg" alt="desk lamp buy desk lamp cheap walnut desk lamp brass lamp best lamp 2026">

<!-- Written for a person: better for everyone, including search -->
<img src="lamp.jpg" alt="Walnut desk lamp with a brushed brass shade on a study desk">

The Corollary Myth: “Every Image Needs Alt Text”

Also wrong. Decorative images should have alt="", which tells a screen reader to skip them. An empty alt is a decision, not an omission. Announcing “wave divider graphic” between two paragraphs makes the page worse.

<img src="wave-divider.svg" alt="" role="presentation">

The alt text guide has the decision tree, and the accessibility mistakes listicle covers the eight barriers that are not alt text at all.

10. “Retina Means You Need 3× Images”

Status: technically true, practically wasteful.

Some phones report a device pixel ratio of 3. Serving 3× assets to them is possible. It is also close to pointless, because file size scales with the square of the dimension while the perceptual gain flattens out.

Density	Pixels served	Relative file size	Visible improvement
1×	400×300	1.0×	Baseline
2×	800×600	~3.5×	Clear
3×	1200×900	~7.5×	Very hard to see

At normal phone viewing distance, on a display already above 400 PPI, the difference between 2× and 3× is not something people can reliably identify. You are paying more than double the bytes for it.

The Practical Rule

Cap at 2×, and drop quality slightly on high-density variants. A 2× image at quality 70 looks better than a 1× image at quality 90 and is often a similar size, because the extra resolution hides compression artifacts.

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

Let srcset and the browser decide. Do not hand-pick densities. See the retina guide.

11. “The CDN Will Handle It”

Status: half true, and the half people rely on is the wrong one.

A CDN caches and delivers. An image CDN also transforms. Even then, it cannot fix what happens in the browser.

Problem	Does a CDN fix it?
Distance latency	Yes
Origin load	Yes
Format negotiation	Yes, if it is an image CDN
Serving the wrong width	Only if your markup requests the right width
Lazy-loaded LCP image	No
Missing width and height	No
Image injected by JavaScript	No
Wrong format for the content	No
Missing alt text	No

The four “no” rows are markup problems. A CDN sends whatever your HTML asks for, as fast as physically possible. If the HTML asks for the wrong thing, it delivers the wrong thing quickly.

The Inverse Myth: “CDNs Are Only for Big Sites”

Also wrong, but for a different reason. The strongest case for an image CDN is rarely traffic volume. It is that variant generation, upload normalisation, and uncontrolled uploaders are work that never finishes, and moving that work to delivery is what stops it recurring. A 300-page site with a CMS that non-developers upload to has a better case than a 50,000-page static site maintained by engineers.

The 8 signs listicle covers when it is and is not worth it, including six cases where you should not bother.

Testing Any Image Claim Yourself

Most of these myths survive because nobody measures. Three commands settle almost any argument:

# 1. What is actually in this file?
magick identify -verbose photo.jpg | head -30
exiftool photo.jpg

# 2. Does setting X change anything visible?
for q in 100 90 85 80 75; do
  magick photo.tif -quality $q "/tmp/q$q.jpg"
done
# then open them side by side at 100%

# 3. What does the browser actually download?
# DevTools → Network → filter Img → add the Dimensions column

And in the browser:

[...document.querySelectorAll('img')].map(img => ({
  file: img.currentSrc.split('/').pop(),
  natural: `${img.naturalWidth}x${img.naturalHeight}`,
  css: `${Math.round(img.clientWidth)}x${Math.round(img.clientHeight)}`,
  dpr: devicePixelRatio,
  waste: +(img.naturalWidth / (img.clientWidth * devicePixelRatio || 1)).toFixed(1)
})).forEach(r => console.table([r]));

Summary

#	Myth	Reality
1	300 DPI is sharper	Browsers ignore DPI entirely
2	WebP/AVIF not supported	Universal since 2021 and 2022
3	Lazy load everything	Never lazy load the LCP image
4	PNG is higher quality	Lossless suits structure, lossy suits photographs
5	Quality 100 is lossless	Still lossy; ask for lossless explicitly
6	Compression always shows	A wide invisible band exists; find the knee
7	Fewer images is faster	Bytes matter, request count mostly does not
8	SVG is always smaller	Only for drawn assets, never for photographs
9	Alt text is for SEO	It is for people; search reads it second
10	Retina needs 3×	Cap at 2×, let srcset choose
11	The CDN handles it	It cannot fix your markup

Checklist

1. ✅ Nobody on the team still exports “at 300 DPI”
2. ✅ AVIF and WebP are being served, with fallbacks
3. ✅ The LCP image is not lazy loaded
4. ✅ Format matches content type, not a blanket preference
5. ✅ Lossless is requested explicitly where it is genuinely needed
6. ✅ Quality settings came from a comparison, not a habit
7. ✅ Optimization targets bytes, not image count
8. ✅ SVG is used only for drawn assets, and runs through SVGO
9. ✅ Alt text reads well aloud, and decorative images use alt=""
10. ✅ Density variants stop at 2×
11. ✅ Markup problems are fixed in markup, not delegated to the CDN

Myths 3 and 11 cost the most, because both feel like optimizations while actively hurting. If you check only two things from this list, check whether your hero image is lazy loaded and whether anyone is treating the CDN as a substitute for correct markup.