DEV Community: Muhaymin Bin Mehmood

Product Image Sizes for Amazon, Shopify, Etsy and Daraz, Checked Against the Official Pages

Muhaymin Bin Mehmood — Mon, 26 Oct 2026 14:00:00 +0000

Search "Amazon image size" and you get twenty blog posts with slightly different numbers. When I built marketplace presets for an image tool, I went to each marketplace's own documentation instead. Several popular "specs" turned out not to be in the official docs at all.

Here's what the official pages say, split into required (upload fails or the listing breaks) and recommended (it works, but looks worse).

Amazon

From Amazon's public product image guide:

Required: 500 px minimum and 10,000 px maximum on the longest side. Formats: JPEG, TIFF, PNG or non-animated GIF.
Required for the main image: pure white background (RGB 255, 255, 255), the product filling about 85% of the frame, shown once, nothing cut off.
Recommended: over 1,000 px on the longest side, which enables zoom. JPEG is the preferred format. At least 72 dpi, RGB colour.
Note: Amazon asks you not to enlarge small images artificially.

Shopify

Limits: up to 5000×5000 px, up to 25 megapixels, under 20 MB per image.
Recommended: 2048×2048 px squares usually display best.
Shopify serves WebP to browsers that support it automatically, so you don't have to upload WebP yourself.

Etsy

Accepted: .jpg, .gif, .png, .svg and .heic. Animated GIFs aren't supported.
Recommended: at least 2000 px on each side. The first listing photo should be at least 635 px.
Watch out: transparent PNGs aren't supported for listings; transparent areas can render black. Flatten onto white (JPG output does this).
Etsy crops thumbnails to square, portrait and landscape, so leave space around the product. The first photo should be landscape or square.
Images over 1 MB may not finish uploading on a slow connection, and Etsy converts images to sRGB.

Daraz

From Daraz's own "Daraz Image Guidelines" document:

Required: JPEG or PNG, square 1:1, white #FFFFFF background on the main image.
Recommended: a minimum resolution of 1024 px, and files between 100 KB and 1 MB.

Blog "specs" for Daraz like a 500 to 2000 px range, a 5 MB cap, JPG-only or "minimum 3 images" are not in that document. I left them out.

The resizing rules that follow from this

Put the four side by side and a few rules hold everywhere:

Never upscale. Amazon says so explicitly, and on every platform an enlarged photo only looks soft at zoom. If a photo is under the recommended size, that's a reshoot, not a resize.
Resize by the long edge, keep the aspect ratio. For Shopify or Daraz squares, pad with white instead of cropping, so nothing gets cut off.
Flatten transparency before uploading to Amazon or Etsy main images.
Same settings for the whole catalogue. Mixed sizes and backgrounds make a category page look messy, even when every image passes on its own.

In code, "never upscale" is one line people forget:

function fitLongEdge(w, h, maxEdge) {
  const scale = Math.min(1, maxEdge / Math.max(w, h)) // never above 1
  return { width: Math.round(w * scale), height: Math.round(h * scale) }
}

fitLongEdge(4032, 3024, 2000) // { width: 2000, height: 1500 }
fitLongEdge(900, 900, 2000) // { width: 900, height: 900 }, left alone

The full table, kept up to date

Rules change, which is how outdated blog posts happen. I keep a marketplace image requirements page with each rule, a link to the official source, and the date it was last checked.

To apply the rules to a folder of photos, the free bulk image resizer on BatchSet resizes many images at once by pixels or percentage with the aspect ratio kept, in the browser, and gives you a ZIP.

This article was drafted with an AI assistant. Every rule above was checked against the marketplace's own documentation on the dates noted on the requirements page.

You Downloaded a .webp and Nothing Opens It. What Happened and 3 Ways Out

Muhaymin Bin Mehmood — Sun, 25 Oct 2026 14:00:00 +0000

You see a product photo, right-click, "Save image as", and get image.webp. Your upload form rejects it, an older editor can't open it, and the person you sent it to asks what a WebP is.

The website probably never "uploaded a WebP". Your browser asked for one.

How you ended up with WebP

When a browser requests an image, it sends an Accept header listing formats it understands, including image/webp and often image/avif. Most image CDNs read that header and send the smallest format the browser supports. The store owner uploaded a JPG. The CDN converted it on the fly, and "Save image as" saved what actually arrived.

I wrote about this in more detail in Your Image CDN Picks the Format, including how to see what a CDN really sends.

WebP itself is a good format. Lossy WebP is usually smaller than a JPEG of similar quality, and it supports transparency, which JPEG doesn't. The problem is only compatibility outside the browser: some desktop apps, print services and upload validators still expect JPG or PNG.

Check what the file really is

Extensions lie in both directions. Look at the first 12 bytes:

async function realType(file) {
  const b = new Uint8Array(await file.slice(0, 12).arrayBuffer())
  const s = (i, j) => String.fromCharCode(...b.subarray(i, j))
  if (s(0, 4) === "RIFF" && s(8, 12) === "WEBP") return "webp"
  if (b[0] === 0xff && b[1] === 0xd8 && b[2] === 0xff) return "jpeg"
  if (s(1, 4) === "PNG") return "png"
  if (s(4, 8) === "ftyp") return "heic/avif family" // check the brand at 8-12
  return "unknown"
}

A WebP always starts with RIFF, four size bytes, then WEBP. If your "photo.jpg" starts that way, it's a WebP with the wrong name, and some programs will refuse it for exactly that reason.

Way out 1: ask for a JPG instead

Because the CDN decided by the Accept header, you can often get the original format by asking without WebP in the list. Copy the image address and:

curl -s -o photo.jpg -H "Accept: image/jpeg" "https://example.com/path/to/image"

Then check the bytes with the function above. This works on many CDNs, not all. Some serve WebP whatever you ask, and some URLs point to a WebP original.

Way out 2: convert to JPG

For photos going to upload forms, email or print, JPG is the safe choice. One thing to get right: JPEG has no transparency. Any transparent pixels have to become a colour, and if a converter doesn't choose one, many viewers show them as black. Fill with white first:

async function webpToJpg(file, quality = 0.9) {
  const bitmap = await createImageBitmap(file)
  const canvas = new OffscreenCanvas(bitmap.width, bitmap.height)
  const ctx = canvas.getContext("2d")
  ctx.fillStyle = "#ffffff"
  ctx.fillRect(0, 0, canvas.width, canvas.height)
  ctx.drawImage(bitmap, 0, 0)
  bitmap.close()
  return canvas.convertToBlob({ type: "image/jpeg", quality })
}

Way out 3: convert to PNG when transparency matters

Logos, icons and cut-out product shots often use transparency. Converting those to JPG puts a white box behind them. Use PNG instead: it's lossless and keeps the alpha channel. The file will be bigger than the WebP, sometimes several times bigger, because PNG doesn't use lossy compression. That's the price of an exact copy.

Quick rule:

You have	Going to	Pick
A photo	Form, email, print	JPG
A logo or cut-out	Editing, design tools	PNG
Anything	Your own website	Keep WebP

If you have many

Converting one file in an editor is fine. For a folder of them, BatchSet has free converters for WebP to JPG (transparent areas filled with white) and WebP to PNG (transparency kept). Both run in the browser, so the images aren't uploaded, and you download everything as one ZIP.

This article was drafted with an AI assistant. The byte check was tested against real WebP, PNG and JPEG files before publishing.

Re-Saving a JPEG at Quality 90 Can Make It Bigger. Measure Before You "Compress"

Muhaymin Bin Mehmood — Sat, 24 Oct 2026 14:00:00 +0000

A common bug report for image tools: "I compressed my photo and the file got bigger." It sounds impossible. It isn't, and it's worth understanding, because the same mistake shows up in build pipelines and CMS plugins.

Quality is not "percent of the original"

When you save a JPEG at quality 90, the 90 doesn't mean "90% of the file you opened". It selects a set of quantization tables, which control how much detail the encoder throws away. The encoder doesn't know or care how the input was saved before.

So take a photo that was saved at quality 75, open it, and save it at quality 90. The encoder now spends more bits per block than the original did. It carefully preserves detail, including the blocky artefacts from the first save. The result looks no better than the q75 file, and it's larger.

Measure it yourself

This Node script takes any JPEG and re-encodes it at a few qualities, then saves it ten times in a row at quality 90:

// node resave.mjs photo.jpg
import { readFile } from "node:fs/promises"
import sharp from "sharp"

const original = await readFile(process.argv[2])
console.log("original".padEnd(12), (original.length / 1024).toFixed(0), "KB")

for (const quality of [95, 90, 80, 70]) {
  const out = await sharp(original).jpeg({ quality }).toBuffer()
  console.log(`q${quality}`.padEnd(12), (out.length / 1024).toFixed(0), "KB")
}

let gen = original
for (let i = 1; i <= 10; i++) gen = await sharp(gen).jpeg({ quality: 90 }).toBuffer()
console.log("10x q90".padEnd(12), (gen.length / 1024).toFixed(0), "KB")

Here's one run on a synthetic test image (random noise, 1600×1200, originally saved at quality 75). Real photos will give different numbers, so treat this as a demonstration and run it on yours:

original     613 KB
q95          918 KB
q90          770 KB
q80          639 KB
q70          584 KB
10x q90      761 KB

Three things to notice:

q90 and q95 made it bigger, by 26% and 50%.
Even q80 made it bigger. Only going below the original's quality actually saved bytes.
Ten saves at q90 didn't keep growing. After the first re-encode the size settles. The quality loss from repeated saves is real, but it's mostly in the first generations.

Run it on your own photos. You'll quickly learn where "compression" stops paying for that kind of image.

The rule every compressor needs

Whatever the settings, a compressor must never hand back a bigger file than it was given:

const blob = await encode(file, { type: "image/jpeg", quality })
const grew = blob.size >= file.size
const result = grew
  ? { blob: file, size: file.size, grew: true } // keep the original, say so
  : { blob, size: blob.size, grew: false }

And tell the user when it happens. "Already well compressed, kept the original" is useful information. A silent "-0%" or a larger download is a bug.

What actually reduces a JPEG

If the quality is already low, re-encoding won't save much. These do:

Fewer pixels. A 4000 px photo shown at 1200 px on a page wastes most of its bytes. Resizing usually saves more than any quality setting.
Strip metadata. EXIF, embedded thumbnails and colour profiles can add tens of KB, and EXIF may include GPS location.
Chroma subsampling (4:2:0). Most photo encoders use it by default; check yours does for photos.
A modern format where you control the delivery, like WebP or AVIF on your own site.

And keep the original. Every lossy save throws detail away for good, so compress from the master copy, not from yesterday's compressed export.

Try it on your photos

BatchSet's free JPEG compressor follows these rules: you pick a quality, it shows the size change on every file, and when a re-encode would be bigger it keeps your original and says so. It runs in the browser, so the photos aren't uploaded.

This article was drafted with an AI assistant. The script was run before publishing; the numbers shown come from a synthetic test image, as stated.

Turning a Folder of iPhone Photos Into One PDF, Entirely in the Browser

Muhaymin Bin Mehmood — Fri, 23 Oct 2026 14:00:00 +0000

"Scan these receipts and send me one PDF." Most people do it with their phone camera, so they end up with 12 HEIC photos and a deadline. Building the tool that turns those photos into one PDF in the browser is a nice small project. Here are the parts that took real thought.

1. Decide by bytes whether a file is HEIC

Chrome can't draw HEIC on a canvas, so HEIC photos need decoding first. But you can't trust the extension: a HEIC renamed to .jpg happens, and so does the reverse. So the input step sniffs the first 12 bytes (ftyp plus a HEIC brand) and only sends real HEIC files to the decoder:

async function decodeForPdf(file: File, pool: HeicDecoder): Promise<Blob | null> {
  if ((await sniffImageKind(file)) !== "heic") return null // the canvas can draw it as is
  const res = await pool.convert(file, { format: "jpg", quality: 90, metadata: "none" })
  return res.blob
}

Note metadata: "none". A PDF page doesn't carry EXIF anyway, and dropping it also drops the GPS location iPhones embed. People sending receipts to an accountant rarely mean to include their home coordinates.

(The HEIC decoding itself is a story of its own: native decode in Safari, libheif WASM elsewhere, and one broken method in libheif-js.)

2. Let people fix the page order

Phones sort photos by time, and people take them out of order. A PDF tool without reordering produces a PDF people have to redo.

Keep the order as plain data and make "move" a pure function:

function moveTo<T extends { id: string }>(list: T[], id: string, index: number): T[] {
  const from = list.findIndex((x) => x.id === id)
  if (from === -1) return list.slice()
  const to = Math.max(0, Math.min(list.length - 1, index))
  const out = list.slice()
  const [item] = out.splice(from, 1)
  out.splice(to, 0, item)
  return out
}

Drag-and-drop calls it, and so do up/down arrow buttons. The buttons matter for keyboard users and on phones, where dragging in a long list is painful.

3. Watch the page size

With pdf-lib, the easy path makes each page exactly as big as its image:

const img = await doc.embedJpg(jpegBytes)
const page = doc.addPage([img.width, img.height])
page.drawImage(img, { x: 0, y: 0, width: img.width, height: img.height })

PDF units are points, 72 per inch. A 4032×3024 iPhone photo becomes a page about 56 by 42 inches. It looks fine zoomed to fit on screen, then someone prints it.

So offer real paper sizes, turn the page to match each photo, and fit the photo inside with its aspect ratio kept:

let pw: number, ph: number
if (pageSize === "a4") {
  ;[pw, ph] = iw > ih ? [PageSizes.A4[1], PageSizes.A4[0]] : PageSizes.A4 // landscape photo, landscape page
} else {
  ;[pw, ph] = [iw, ih] // "auto": page matches the image
}
const page = doc.addPage([pw, ph])
const s = Math.min(pw / iw, ph / ih)
page.drawImage(img, { x: (pw - iw * s) / 2, y: (ph - ih * s) / 2, width: iw * s, height: ih * s })

Each page gets its own orientation, so a mix of portrait receipts and one landscape whiteboard photo all fill their pages.

4. Embed JPEG, even for PNG input

embedJpg puts the JPEG bytes into the PDF as they are, with no re-compression. embedPng has to decode the PNG and store the pixels with lossless compression. For photos that makes the PDF several times bigger. So every page is converted to JPEG first. Screenshots with sharp text can go at a higher JPEG quality.

5. One bad photo shouldn't sink the PDF

With 20 files, one is usually odd: a corrupt download, a Live Photo export the decoder doesn't like, a PDF someone dropped by mistake. Failing the whole job at file 17 is the worst outcome.

Instead, mark that one file as unreadable in the list, keep the rest, and let the user decide whether to remove it or try another copy. A clear "1 file couldn't be read" beats an error dialog and an empty result.

6. What this PDF is not

The pages are pictures. You can't search or copy the text in them, because nothing ran OCR. For receipts going to a person that's usually fine. For anything that needs search, see this earlier post on what "searchable" really requires.

Try it

This is how BatchSet's free HEIC to PDF tool works: drop iPhone photos, drag them into order, choose Auto, A4 or Letter, and download one PDF. For screenshots and other PNGs there's PNG to PDF with the same engine. Nothing leaves the browser, which is the point when the photos are receipts or IDs.

This article was drafted with an AI assistant from the code of a production tool. The snippets are taken from that code.

GIF to PNG in the Browser: First Frames, 1-Bit Transparency, and Why the PNG Gets Bigger

Muhaymin Bin Mehmood — Thu, 22 Oct 2026 14:00:00 +0000

GIF to PNG sounds like the simplest conversion there is. Load the image, draw it on a canvas, export PNG. And for a still GIF, that really is all.

But GIFs have quirks, and three of them surprise people every time: animation, transparency and file size.

The one-liner, done properly

async function gifToPng(file) {
  const bitmap = await createImageBitmap(file)
  const canvas = new OffscreenCanvas(bitmap.width, bitmap.height)
  canvas.getContext("2d").drawImage(bitmap, 0, 0)
  bitmap.close()
  return canvas.convertToBlob({ type: "image/png" })
}

OffscreenCanvas lets this run in a Web Worker, so converting 30 files doesn't freeze the page.

Quirk 1: an animated GIF gives you one frame

Draw an animated GIF to a canvas and you get a single frame. That's not a bug. The HTML spec says that when an animated image is drawn, the browser uses its "default image", and if the format doesn't define one, the first frame. createImageBitmap follows the same rule.

So for an animated GIF, the code above gives you a still PNG of frame one. For thumbnails, previews and "I just need a still of this", that's exactly right.

Can PNG animate? Yes, sort of. APNG is an extension of PNG that stores frames, and modern browsers play it. But many apps, upload forms and image editors only read the first frame of an APNG. If the goal is "keep it moving", stay with the GIF or export a short video (MP4 or WebM are far smaller than either).

Getting every frame when you need them

If you want all the frames, for a sprite sheet or to inspect an animation, use the WebCodecs ImageDecoder API, available in Chromium-based browsers (check support for your audience):

async function gifFrames(file) {
  const decoder = new ImageDecoder({ data: file.stream(), type: "image/gif" })
  await decoder.tracks.ready
  const count = decoder.tracks.selectedTrack.frameCount
  const frames = []
  for (let i = 0; i < count; i++) {
    const { image } = await decoder.decode({ frameIndex: i }) // a VideoFrame
    frames.push(image)
  }
  return frames // draw each with ctx.drawImage(frame, 0, 0), then frame.close()
}

Close each VideoFrame when you're done. They hold real memory, and a 200-frame GIF adds up fast.

Quirk 2: GIF transparency is on or off, never partial

A GIF pixel is either fully transparent or fully opaque. There's no 50% alpha. That's why GIF logos have jagged edges on dark backgrounds: the anti-aliasing was blended against a background colour (usually white) when the GIF was made.

Converting to PNG keeps the transparency exactly, but it can't invent the smooth edges that were never there. If edges look rough, the fix is a better source (an SVG or the original PNG), not a different converter.

The opposite trap: if you ever convert that PNG on to JPEG, there's no alpha at all. Fill the canvas with white first, or the transparent areas turn black in many viewers.

Quirk 3: the PNG is often bigger than the GIF

People expect a "better" format to be smaller. Here it often isn't.

A GIF stores at most 256 colours, as palette indexes, one byte per pixel or less. Canvas exports a PNG with full 8-bit RGBA, four bytes per pixel before compression. Same picture, more data to describe it. For flat graphics the PNG can easily come out larger.

That's fine when you need a lossless still for editing or printing. If size matters more, run the PNG through a palette quantizer (tools like pngquant do this) or pick WebP for the web.

When to convert at all

Convert when you need a still image for an upload form, a document, a design tool, or editing.
Keep the GIF when the animation is the point.
Use video when the animation is long or large.

For the first case, BatchSet's free GIF to PNG converter does exactly what this post describes: lossless PNG, transparency kept, the first frame for animated GIFs, several files at once with a ZIP download, and nothing uploaded.

This article was drafted with an AI assistant. The code follows the browser APIs as specified; test ImageDecoder support for your target browsers.

Writing a .ico File by Hand in 40 Lines of JavaScript

Muhaymin Bin Mehmood — Wed, 21 Oct 2026 14:00:00 +0000

Browsers are happy with a PNG favicon these days. But favicon.ico still matters: some crawlers, old browsers, Windows shortcuts and RSS readers request /favicon.ico directly, whatever your HTML says.

I assumed making one needed a native tool or a heavy library. It doesn't. An .ico file is one of the simplest binary formats you'll ever write.

The whole format on one screen

An ICO file has three parts:

ICONDIR        6 bytes      reserved=0, type=1 (icon), count
ICONDIRENTRY  16 bytes      one per image: width, height, ..., size, offset
image data    N bytes       the images, back to back

The key fact that makes this easy: since Windows Vista, the image data inside an ICO can be a complete PNG file. Every current browser accepts that too. So you don't need to produce old-style BMP bitmaps with AND masks. You render PNGs at 16, 32 and 48 pixels and pack them.

The encoder

interface IcoImage {
  size: number // square edge in px
  png: Uint8Array // raw PNG bytes for this size
}

export function encodeIco(images: IcoImage[]): Blob {
  const count = images.length
  const header = new Uint8Array(6)
  const hv = new DataView(header.buffer)
  hv.setUint16(0, 0, true) // reserved, must be 0
  hv.setUint16(2, 1, true) // type: 1 = icon (2 would be a cursor)
  hv.setUint16(4, count, true)

  const dir = new Uint8Array(count * 16)
  const dv = new DataView(dir.buffer)
  let offset = 6 + count * 16 // first image starts right after the directory

  images.forEach((img, i) => {
    const b = i * 16
    const dim = img.size >= 256 ? 0 : img.size // 0 means 256
    dv.setUint8(b + 0, dim) // width
    dv.setUint8(b + 1, dim) // height
    dv.setUint8(b + 2, 0) // palette colours (0 = none)
    dv.setUint8(b + 3, 0) // reserved
    dv.setUint16(b + 4, 1, true) // colour planes
    dv.setUint16(b + 6, 32, true) // bits per pixel
    dv.setUint32(b + 8, img.png.length, true) // payload size
    dv.setUint32(b + 12, offset, true) // payload offset
    offset += img.png.length
  })

  return new Blob([header, dir, ...images.map((im) => im.png)], { type: "image/x-icon" })
}

Three details that trip people up:

Little-endian. ICO comes from Windows, so every multi-byte number is little-endian. That's the true in each setUint16 and setUint32. Forget it and the file looks valid in a hex editor but no program can read it.
One byte for the size. Width and height get one byte each, so 256 can't fit. The spec says to write 0, which means 256.
Offsets are absolute. Each entry stores where its PNG starts from the beginning of the file. That's why offset starts at 6 + count * 16.

Getting the PNGs

In the browser, render each size on a canvas and export it:

async function pngAt(source: ImageBitmap, size: number): Promise<Uint8Array> {
  const canvas = new OffscreenCanvas(size, size)
  const ctx = canvas.getContext("2d")!
  ctx.imageSmoothingQuality = "high"
  ctx.drawImage(source, 0, 0, size, size)
  const blob = await canvas.convertToBlob({ type: "image/png" })
  return new Uint8Array(await blob.arrayBuffer())
}

const bitmap = await createImageBitmap(file)
const images = await Promise.all([16, 32, 48].map(async (size) => ({ size, png: await pngAt(bitmap, size) })))
const ico = encodeIco(images)

Transparency survives, because PNG keeps the alpha channel.

Which sizes?

16×16 is the browser tab. 32×32 covers high-DPI tabs and Windows taskbar shortcuts. 48×48 is used by Windows for desktop icons. Put all three in one file, and each consumer picks the closest one.

Shrinking a detailed logo to 16 pixels usually turns it to mush. If your logo has fine text, draw a simpler mark for the 16 px version and pass that PNG instead of a downscaled one. The encoder doesn't care where each PNG came from.

Shipping it

Put the file at /favicon.ico on your site root. For the rest of the favicon setup (<link> tags, the web manifest, Apple touch icons and cache problems), I wrote a separate post.

If you just need the file, this encoder runs inside BatchSet's free PNG to ICO converter (16, 32 and 48 px in one .ico), and the favicon generator builds the full set. Both work in the browser without uploading your logo.

This article was drafted with an AI assistant from the code of a production tool. The encoder is taken from that code.

Why Does Chrome Save Images as .jfif? (It's a JPEG Wearing a Different Name)

Muhaymin Bin Mehmood — Tue, 20 Oct 2026 14:00:00 +0000

You right-click an image in Chrome or Edge, choose "Save image as", and get photo.jfif. Then a job portal, a marketplace or a CMS refuses it: "Only JPG, JPEG or PNG allowed."

Nothing is wrong with the image. A .jfif file is a JPEG. Only the name is different.

What JFIF actually is

JPEG is the compression method. JFIF (JPEG File Interchange Format) is the most common file layout for storing JPEG data. It adds a small header with things like the version and pixel density. Most files you've ever called "a JPG" are JFIF files inside.

You can check it from the first bytes. Every JPEG starts with FF D8 FF. A JFIF one usually follows with an APP0 segment that literally contains the text JFIF:

async function describe(file) {
  const b = new Uint8Array(await file.slice(0, 12).arrayBuffer())
  const isJpeg = b[0] === 0xff && b[1] === 0xd8 && b[2] === 0xff
  const jfif = String.fromCharCode(...b.subarray(6, 11)) === "JFIF\0"
  return { isJpeg, jfif }
}

Run that on a .jfif download and on a .jpg from your camera. Both say isJpeg: true.

So why the weird extension?

The browser asks the operating system which extension belongs to the image/jpeg content type. On many Windows machines the answer is .jfif, because of one registry value:

HKEY_CLASSES_ROOT\MIME\Database\Content Type\image/jpeg
    Extension    REG_SZ    .jfif

You can look at yours without changing anything:

reg query "HKEY_CLASSES_ROOT\MIME\Database\Content Type\image/jpeg" /v Extension

If it says .jfif, that's the whole story. Some installed program changed it, and every browser on that machine now follows it.

Three fixes, from smallest to biggest

1. Rename the file. Change photo.jfif to photo.jpg. The bytes are identical, so this is a complete fix, not a hack. In Windows Explorer you may need View → Show → File name extensions to see the extension.

2. Fix the registry value (affects future downloads). Change Extension to .jpg under the key above. Editing the registry is at your own risk: export the key first so you can restore it.

3. Convert, when renaming isn't possible. Some people can't rename easily (locked-down work laptops, phones, or 40 files at once). Then a converter that re-saves the files as .jpg is the practical route.

Why upload forms reject it

Most upload validation checks the extension or the browser-reported MIME type, not the bytes. accept=".jpg,.jpeg,.png" on an input element filters by extension, so a .jfif file never shows up in the picker or fails the check.

If you build upload forms, two small changes save your users this trouble:

<input type="file" accept="image/jpeg,image/png,.jfif">

And on the server, decide by the first bytes (FF D8 FF for JPEG), not by the name. That also stops the opposite problem: a PNG renamed to .jpg passing your check.

A quick way to do many files

If you have a folder of .jfif files and renaming them one by one isn't fun, BatchSet has a free JFIF to JPG converter. You drop several at once and download a ZIP of .jpg files. It runs in the browser, so the images aren't uploaded.

The short version: .jfif is a JPEG with a Windows naming quirk. Rename it, fix the registry value, or batch-convert. And if you write upload forms, check the bytes, not the extension.

This article was drafted with an AI assistant. The byte check and the registry query were tested before publishing.

Changing an Image to 300 DPI Without Touching a Single Pixel

Muhaymin Bin Mehmood — Mon, 19 Oct 2026 14:00:00 +0000

"Please upload the image at 300 DPI." Print shops, journals and some government forms say this. Most people then open an editor, find a resize dialog, and accidentally resample the photo, making it bigger, blurrier or both.

Here's the thing: DPI is metadata. It's a number in the file header that tells a printer how many pixels to put in one inch. A 3000×2000 photo at 300 DPI prints at 10×6.67 inches. The same photo at 72 DPI prints at about 41.7×27.8 inches. The pixels are identical in both cases.

So changing DPI should change a few header bytes and nothing else. No decode, no re-encode, no quality loss, and EXIF untouched. Here's where those bytes live.

PNG: one place, in metres

PNG stores density in the pHYs chunk: 4 bytes X, 4 bytes Y, 1 byte unit. The unit 1 means pixels per metre, so 300 DPI is stored as 11811.

Reading it means walking the chunks until you find it:

function pngDpi(b) {
  const view = new DataView(b.buffer, b.byteOffset, b.byteLength)
  let p = 8 // skip the 8-byte signature
  while (p + 8 <= b.length) {
    const len = view.getUint32(p)
    const type = String.fromCharCode(...b.subarray(p + 4, p + 8))
    if (type === "pHYs") {
      const ppmX = view.getUint32(p + 8)
      const unit = b[p + 16] // 1 = metre
      return unit === 1 ? Math.round(ppmX * 0.0254) : null
    }
    if (type === "IDAT") break // density must come before the image data
    p += 12 + len // length + type + data + CRC
  }
  return null
}

Writing it means building a new 21-byte chunk (length, type, 9 data bytes, CRC-32) and inserting it before the first IDAT, or replacing the old one. Don't forget the CRC, or strict readers will reject the file.

JPEG: two places, and they can disagree

JPEG has two homes for density:

The JFIF APP0 segment: units, X density, Y density.
The EXIF APP1 segment: XResolution, YResolution, ResolutionUnit. This is what Photoshop and Windows Explorer show.

You'd think every JPEG has a JFIF segment. I listed the segments of a 300 DPI JPEG written by sharp:

let p = 2
while (b[p] === 0xff && b[p + 1] !== 0xda) {
  const marker = b[p + 1].toString(16)
  const len = (b[p + 2] << 8) | b[p + 3]
  console.log("FF" + marker, len, String.fromCharCode(...b.subarray(p + 4, p + 10)))
  p += 2 + len
}

FFe1 188 Exif..
FFe2 496 ICC_PR
FFdb 67 ...

No APP0 at all. The 300 DPI lives only in EXIF. A tool that only edits JFIF would "change the DPI" of this file and change nothing anyone can see.

The reverse happens too: files with JFIF saying 72 and EXIF saying 300. Different programs then show different answers for the same file. The safe rule: write every place that already exists, with the same value. Add a JFIF segment if there's none, and update EXIF if it's present.

The bug my own tests couldn't see

My first version passed 29 tests. They wrote a DPI, read it back with my own parser, and compared. Of course they passed: the writer and the reader shared the same assumptions.

Then I checked the output with sharp, which uses libvips, a completely independent reader. Some PNGs came back with the old DPI.

The cause: PNGs written by sharp or Photoshop can carry an eXIf chunk, a full EXIF block inside the PNG, with its own resolution tags. libvips reads eXIf in preference to pHYs. My code updated pHYs correctly and left the stale eXIf value in place, so to libvips the DPI never changed.

Two lessons:

When a PNG has eXIf, update its resolution tags too.
Verify header writes with a reader you didn't write. Round-tripping through your own parser only proves your writer and reader agree with each other.

What DPI can't do

Changing DPI never adds detail. If a print shop needs a 10-inch-wide print at 300 DPI, they need 3000 pixels across. A 1200-pixel photo set to 300 DPI just prints at 4 inches. A good tool should show that print size next to the DPI field, so nobody is surprised at the counter.

The tool

This header-only approach is how the free DPI converter on BatchSet works: pick 72, 150, 300 or 600 DPI for a JPG or PNG, and only the header bytes change. It runs in the browser, so the file isn't uploaded. WebP is rejected on purpose, because it has no standard density field, and silently returning an unchanged file would be worse than an error.

This article was drafted with an AI assistant from the code of a production tool. The snippets were run against real files before publishing.

"Photo Must Be Under 50 KB": Writing the Search That Hits a File-Size Limit

Muhaymin Bin Mehmood — Sun, 18 Oct 2026 14:00:00 +0000

Exam portals, visa forms and job sites love rules like "photo between 20 KB and 50 KB, JPG only". A phone photo is 3 to 5 MB. The person filling the form doesn't care about quality settings. They care that the upload button stops saying "file too large".

I covered why "quality 80" can't promise a size in an earlier post. This post is the follow-up: the actual search that finds a JPEG under a byte limit, without wasting dozens of encodes.

What "best" means here

There are many JPEGs under 50 KB. A 40×40 thumbnail is one of them. The goal is the largest file that still fits, because for the same image a bigger JPEG almost always looks better.

That gives two knobs, in a clear order:

Quality. Try this first. It keeps every pixel.
Pixel count. Use this only when even low quality is too big. A 12 MP photo can't reach 20 KB on quality alone.

Keep the search pure

The search doesn't know about canvas, workers or blobs. The caller passes an encode function that returns a byte count:

type Attempt = { scale: number; quality: number } // scale 0-1, quality 10-95

async function searchTargetSize(
  targetBytes: number,
  encode: (a: Attempt) => Promise<number>,
  opts: { longSide: number; minLongSide?: number; maxAttempts?: number },
)

That makes it unit-testable with a fake encoder. It also runs unchanged on the main thread or in a worker that owns an OffscreenCanvas.

Phase 1: binary search on quality

Try full size at quality 95 first. If it already fits, you're done and the user gets maximum quality.

If not, binary-search quality in steps of 5. Finer steps barely move the byte count, so they waste encodes.

const searchQuality = async (scale: number, hi: number, steps: number) => {
  let low = 10
  let high = hi
  for (let i = 0; i < steps && attempts < maxAttempts && low <= high; i++) {
    const mid = Math.round((low + high) / 2 / 5) * 5
    const bytes = await tryOne({ scale, quality: mid })
    if (bytes <= targetBytes) low = mid + 5 // fits: try higher quality
    else high = mid - 5 // too big: go lower
  }
}

tryOne records two things on every encode: the best attempt that fits (largest bytes under the limit), and the smallest attempt seen overall. It also caches by scale|quality, so the same attempt is never encoded twice.

Phase 2: shrink, but measure instead of stepping

If quality 10 at full size is still too big, the image has too many pixels. The obvious loop shrinks by a fixed 15% each time. That works, but it's slow. Going from 690 KB to 20 KB that way takes about 11 encodes.

There's a better guess available. JPEG size roughly tracks pixel count, and pixel count goes with the square of the scale. So read the next scale straight off the last measurement:

let scale = 1
let lowBytes = await tryOne({ scale: 1, quality: 10 })

while (!found.best && attempts < maxAttempts && scale > minScale) {
  const next = Math.max(minScale, scale * Math.sqrt(targetBytes / lowBytes) * 0.97)
  if (next >= scale) break // no progress possible
  scale = next
  lowBytes = await tryOne({ scale, quality: 10 })
  if (lowBytes <= targetBytes) {
    await searchQuality(scale, 85, 4) // it fits: spend the rest on quality
  }
}

Two details:

The 0.97 aims slightly under the target, because the square-root rule is an estimate.
Once a size fits at quality 10, the loop goes back to quality search at that size. A smaller image at quality 70 usually beats a bigger one at quality 10.

In practice this lands in one or two shrink steps instead of eleven.

Guard rails

A floor on size. Never go below 320 px on the long side. Below that, a face photo stops being useful, and the form will reject it for other reasons.
A cap on encodes. 16 attempts maximum, so a pathological image can't spin forever.
Honest failure. If nothing fits, return the smallest attempt with met: false and tell the user. Don't silently hand over a file that's still too big.

Always JPEG

For this use case the output is always JPEG. PNG is lossless, so the only way to shrink it is fewer pixels, and a photo PNG at 50 KB is tiny and blurry. Forms almost always accept JPG anyway.

Try it

This search runs in the browser behind BatchSet's reduce image size in KB tool, where you type any target. For the most common form limit there's a preset page, compress image to 50 KB. Nothing is uploaded, which matters when the photo is for an ID document.

The pattern works beyond images too. Any time you have an expensive "try it and measure" step and a monotonic knob, binary-search the cheap knob first and use the measurements to jump on the expensive one.

This article was drafted with an AI assistant from the code of a production tool. The snippets are taken from that code.

Decoding iPhone HEIC Photos in the Browser With libheif WASM (and the One-Line Bug That Broke It)

Muhaymin Bin Mehmood — Sat, 17 Oct 2026 14:00:00 +0000

Every iPhone since iOS 11 saves photos as HEIC by default. Send one to a Windows laptop, an upload form or an older CMS and it often fails. The usual fix is an online converter that uploads your photo to a server.

You don't need the server. A browser can decode HEIC itself, and where it can't, a WebAssembly build of libheif can. Here's how that pipeline works, including a bug in libheif-js that cost me an afternoon.

Step 1: check the bytes, not the file name

People rename files. A HEIC saved as .jpg exists, and so does a JPEG saved as .heic. So the first job is to read the file header.

HEIF files are ISO-BMFF containers. Bytes 4 to 8 spell ftyp, and bytes 8 to 12 are the "major brand":

const HEIC_BRANDS = ["heic", "heix", "hevc", "hevx", "heim", "heis", "hevm", "hevs", "mif1", "msf1"]

function ascii(b, start, end) {
  let s = ""
  for (let i = start; i < end && i < b.length; i++) s += String.fromCharCode(b[i])
  return s
}

async function isHeic(file) {
  const b = new Uint8Array(await file.slice(0, 12).arrayBuffer())
  if (b.length < 12 || ascii(b, 4, 8) !== "ftyp") return false
  return HEIC_BRANDS.includes(ascii(b, 8, 12).toLowerCase())
}

mif1 and msf1 matter. Some phones and editors write those generic brands instead of heic.

Step 2: let the browser try first

Safari 17 and later can decode HEIC natively. If createImageBitmap(file) works, you're done, and you never download any WASM:

async function tryNative(file) {
  try {
    return await createImageBitmap(file, { imageOrientation: "from-image" })
  } catch {
    return null // Chrome, Firefox and Edge on most systems end up here
  }
}

Step 3: fall back to libheif, loaded only when needed

For everyone else, libheif compiled to WebAssembly does the decoding. It's about 520 KB gzipped, so import it lazily, the first time a HEIC file actually shows up:

let libPromise = null

function loadLibheif() {
  libPromise ??= import("libheif-js/libheif-wasm/libheif-bundle.mjs")
    .then(async (m) => {
      const lib = m.default()
      if (lib.ready) await lib.ready
      return lib
    })
    .catch((err) => {
      libPromise = null // one failed chunk load must not break every later photo
      throw err
    })
  return libPromise
}

Resetting libPromise in the catch matters. Without it, one flaky network moment poisons every photo after it.

Step 4: pick the primary image, not the first one

A HEIC file can hold several images: the photo, a thumbnail, a depth map. You want the one the container marks as primary. libheif-js has a method for exactly that on each image:

const primary = images.find((im) => im.is_primary()) // don't do this

In libheif-js 1.19.8, HeifImage.prototype.is_primary() calls a global function that doesn't exist, so it throws a ReferenceError. My tests used synthetic files with a single image, so they never reached that line. The first real phone photo did.

The fix is to call the underlying embind export yourself and treat any failure as "not primary":

function isPrimary(lib, im) {
  try {
    return im.handle !== undefined && !!lib.heif_image_handle_is_primary_image(im.handle)
  } catch {
    return false
  }
}

const primary = images.find((im) => isPrimary(lib, im)) ?? images[0]

Lesson: test with real files from real phones. Synthetic files only exercise the code paths you already thought about.

Step 5: refuse huge photos before you allocate

Decoding gives you raw RGBA, four bytes per pixel. A 48 MP photo is about 190 MB before you've drawn anything. I refuse anything over 64 MP before decoding (a 64 MP RGBA buffer is about 256 MB), and free every image handle and the decoder in a finally block, including on failure.

Orientation is the easy part. libheif applies the container's rotation and mirror boxes (irot, imir), so the pixels come out upright. When you write the JPG, set EXIF Orientation to 1, or viewers will rotate the photo a second time.

Step 6: one worker per photo, and fewer on phones

Decoding is CPU-heavy, so it runs in Web Workers. The tempting move is one worker per core. On a phone that crashes the tab, because memory runs out before the CPU does. So the pool size depends on the device:

function pickConcurrency({ cores, deviceMemory, mobile }) {
  const c = cores && cores > 0 ? cores : 4
  // A 48 MP decode peaks near 1 GB, and Android's low-memory killer
  // takes the whole tab, not just the worker.
  if (mobile || (deviceMemory !== undefined && deviceMemory <= 4)) return 1
  return Math.max(1, Math.min(4, c))
}

Read the inputs from navigator.hardwareConcurrency, navigator.deviceMemory and navigator.userAgentData?.mobile. Mobile or 4 GB of RAM or less means one photo at a time. It's slower, but the tab survives a batch of 50.

Step 7: keep the useful metadata, drop the GPS

Drawing to a canvas strips all metadata. That's good for privacy, but people do want their capture date in the converted JPG. So after encoding I write a small EXIF block back: date taken, camera and lens. GPS goes in only if the user asks for it.

The result

A HEIC converter built this way never sends the photo anywhere. In the network log there's no image upload at all: just the page, the WASM chunk the first time, and analytics pings. If you'd rather not build it, this is the pipeline behind the free HEIC to JPG converter on BatchSet (there's a HEIC to PNG version for lossless output).

The short version:

Sniff ftyp brands, don't trust extensions.
Try native decode first, load WASM lazily.
Don't call is_primary() in libheif-js 1.19.8.
Size the worker pool by memory, not cores.

This article was drafted with an AI assistant from the code of a production tool. The snippets are taken from that code.

Your Product Photos Might Be Publishing Your Location: EXIF, GPS and How to Strip It in the Browser

Muhaymin Bin Mehmood — Fri, 16 Oct 2026 14:03:21 +0000

A lot of small online shops take product photos on a phone, upload them straight to the store, and move on. That is fast, but the original file usually carries more than pixels. It can include the GPS coordinates of where the photo was taken, the phone model, the exact date and time, and sometimes editing software details.

If you shoot products at home, those coordinates point at your home.

This post covers three things:

What is actually inside a photo's metadata
How to read it in the browser with a few lines of JavaScript
How to strip it in the browser, and the orientation bug that bites almost everyone the first time

What EXIF can contain

EXIF is a block of metadata that cameras and phones write into the image file. The fields that matter for privacy:

Field	Example	Why it matters
GPSLatitude / GPSLongitude	52.52, 13.40	Where the photo was taken, often to within a few meters
DateTimeOriginal	2026:10:11 14:32:07	When you were there
Make / Model	Apple iPhone 15	Your device
Software	a photo editor version	What you used
Orientation	6	How the image should be rotated for display

Phones only write GPS when location access is turned on for the camera app, and many people never turn it off. JPEG is the usual suspect, but WebP, PNG and HEIC files can carry EXIF too.

Some big platforms remove metadata when you upload. Don't assume yours does. The only reliable test is to download the file your visitors actually receive and inspect it.

Step 1: Check a file for metadata

On the command line, exiftool is the standard:

exiftool -gps:all -DateTimeOriginal -Model product-photo.jpg

In the browser, the exifr library parses metadata locally, so the file never has to leave the user's device:

import exifr from "exifr";

async function inspect(file) {
  const gps = await exifr.gps(file); // { latitude, longitude } or undefined
  const tags = await exifr.parse(file, ["Make", "Model", "DateTimeOriginal"]);

  return {
    hasLocation: Boolean(gps),
    location: gps ? `${gps.latitude.toFixed(5)}, ${gps.longitude.toFixed(5)}` : null,
    device: [tags?.Make, tags?.Model].filter(Boolean).join(" ") || null,
    takenAt: tags?.DateTimeOriginal ?? null,
  };
}

document.querySelector("input[type=file]").addEventListener("change", async (e) => {
  for (const file of e.target.files) {
    console.log(file.name, await inspect(file));
  }
});

Run that over a folder of phone photos once. It is usually a surprise.

Step 2: Strip it by re-encoding

The simplest way to remove everything in the browser is to decode the image and encode it again through a canvas. The canvas only knows pixels, so the new file has no EXIF at all: no GPS, no device, no timestamps.

async function stripMetadata(file, type = "image/jpeg", quality = 0.9) {
  // "from-image" applies the EXIF Orientation tag while decoding.
  const bitmap = await createImageBitmap(file, { imageOrientation: "from-image" });

  const canvas = new OffscreenCanvas(bitmap.width, bitmap.height);
  canvas.getContext("2d").drawImage(bitmap, 0, 0);
  bitmap.close();

  return canvas.convertToBlob({ type, quality });
}

Then confirm the result really is clean:

const clean = await stripMetadata(file);
console.log(await exifr.parse(clean)); // undefined: nothing left to read

The orientation trap

Here is the bug. Phones often save the pixels sideways and add an Orientation tag that says "rotate this 90 degrees when you display it". Browsers respect that tag, so the photo looks fine on screen.

If you strip the metadata without baking the rotation into the pixels first, the tag disappears and the photo shows up sideways.

That is why the code above decodes with imageOrientation: "from-image". The bitmap comes out already rotated, so the pixels are correct and no tag is needed. If you write your own pipeline, test it with a portrait photo straight off a phone before you ship.

Trade-offs to know about

Re-encoding is lossy for JPEG and WebP. Each pass at quality 0.9 costs a little detail. If you want to remove metadata without touching pixels, use exiftool -all= -overwrite_original photo.jpg instead.
Color profiles are replaced, not dropped. A canvas works in its own color space, sRGB by default, and the encoder tags the output with it: in Chrome 154 the stripped JPEG still carried a 456-byte sRGB ICC profile, so the file is not profile-less. What does not survive is the original profile, so a wide-gamut source comes out converted to sRGB and can shift slightly.
HEIC needs converting first. Most browsers can't decode HEIC, so there is nothing to draw onto the canvas. Convert it to JPEG or WebP, which removes the metadata at the same time.
Do it before upload. Stripping on your server still means the original, with its GPS, was sent over the network and possibly logged.

A workflow for a product catalog

For a shop, the easy habit is to strip metadata in the same step where you already resize and compress:

Export photos from the phone.
Resize to the size your store actually displays (often 1200 to 2048 px).
Convert to WebP or JPEG. The re-encode removes EXIF as a side effect.
Spot-check one output file with exiftool or exifr.

If you'd rather not write code, I built a free EXIF viewer and remover that does steps 1 and 4 in the browser, and the bulk image compressor covers steps 2 and 3 for a whole folder. Both run locally, so the photos never upload.

Summary

Phone photos can carry your location, device and timestamps.
Check with exiftool or exifr before you publish.
A canvas re-encode removes all of it. Decode with imageOrientation: "from-image" so portrait photos stay upright.
Re-encoding is lossy and re-tags the file as sRGB; use exiftool when you need lossless removal.

Have you found GPS data in images on a site you run? I'm curious how common it still is.

I wrote this with help from an AI assistant. Both code samples were run against real phone photos and in a real browser before publishing.

Your Image CDN Picks the Format. Here's How to See What It Actually Sends

Muhaymin Bin Mehmood — Mon, 12 Oct 2026 10:52:27 +0000

Here is one image URL from a real Shopify store, requested three times. Same URL, same second, three different files:

https://jellinator.com/cdn/shop/files/ShotCups_100Pack.png?width=1200

  Chrome (AVIF+WebP)   image/webp     87 KB   Vary: Accept
  WebP only            image/webp     87 KB   Vary: Accept
  Old browser          image/png    1223 KB   Vary: Accept

The only thing that changed between the three requests is the Accept header. A browser that says it understands WebP gets an 87 KB file. A client that doesn't gets the original 1.2 MB PNG.

That is content negotiation, and most image CDNs do it now. It's great for visitors. It also means that "what format is this image?" has no single answer, and some tools will give you the wrong one.

The header that decides it

Every browser sends an Accept header with image requests. Current Chrome sends:

Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8

A negotiating CDN reads that list and picks the best format it can produce. It then adds Vary: Accept to the response, which tells every cache in between: "this URL has more than one version, keyed by the Accept header".

If you see Vary: Accept on an image response, the server is negotiating. If you don't, you're getting the same file whatever you ask for.

Check it with curl

curl -I sends a HEAD request and prints the headers. Add the header a browser would send:

curl -sI -H "Accept: image/avif,image/webp,image/*,*/*;q=0.8" \
  "https://jellinator.com/cdn/shop/files/ShotCups_100Pack.png?width=1200" \
  | grep -iE "content-type|content-length|vary"

Then run it again without -H. curl's default is Accept: */*, which is exactly the "old browser" case above. If the two answers differ, your CDN negotiates.

A small script for a list of URLs

When you want to check a batch of images, this does the three requests for each URL and prints one line per client:

// check-formats.mjs: what format does each image URL send to different browsers?
// Usage: node check-formats.mjs <image-url> [more urls...]
const ACCEPTS = {
  "Chrome (AVIF+WebP)": "image/avif,image/webp,image/apng,image/*,*/*;q=0.8",
  "WebP only": "image/webp,image/*,*/*;q=0.8",
  "Old browser": "image/*,*/*;q=0.8",
}

for (const url of process.argv.slice(2)) {
  console.log(`\n${url}`)
  for (const [label, accept] of Object.entries(ACCEPTS)) {
    const res = await fetch(url, { method: "HEAD", headers: { accept } })
    const type = res.headers.get("content-type")
    const size = res.headers.get("content-length")
    const vary = res.headers.get("vary") ?? "-"
    console.log(`  ${label.padEnd(20)} ${type?.padEnd(12)} ${size ? Math.round(size / 1024) + " KB" : "?"}  Vary: ${vary}`)
  }
}

It needs Node 18 or newer (for the built-in fetch). Some servers answer HEAD differently from GET; if a line looks odd, try the same URL with GET.

The size can change the format too

Run the same image at a smaller width and something else happens:

https://jellinator.com/cdn/shop/files/ShotCups_100Pack.png?width=300

  Chrome (AVIF+WebP)   image/avif     14 KB   Vary: Accept
  WebP only            image/webp     16 KB   Vary: Accept
  Old browser          image/png      98 KB   Vary: Accept

At 300px this CDN sent AVIF to Chrome. At 1200px it sent WebP, even though Chrome said it accepts AVIF.

We saw the same pattern across a larger sample. In a study of 199 Shopify product pages, 94.2% of image files came back as WebP or AVIF, and 97.2% of those responses carried Vary: Accept. But when we spot-checked the main product photo of 24 stores at 600px, 22 came back as WebP and none as AVIF. AVIF showed up on some small variants, and not consistently.

So "my CDN supports AVIF" and "my product photos are served as AVIF" are two different claims. Check the second one directly.

Why some audits get this wrong

Any tool that fetches your images without a browser-like Accept header sees the "old browser" version. For the image above, that's a 1.2 MB PNG instead of an 87 KB WebP, so the tool reports a problem your visitors never have.

When you read an image audit, check one thing: does it say which Accept header it used? If it doesn't, compare a couple of its numbers with the script above before you start re-exporting files.

The reverse mistake happens too. If you test only with Chrome DevTools, you see the best case. Visitors on old browsers, some email clients and some social link previews may get the original file.

Caching: don't break Vary

Negotiation only works if every cache between the CDN and the visitor respects Vary: Accept. If you put your own proxy or a second CDN in front of your images and it ignores Vary, the first visitor's format gets cached for everyone. An old client's PNG can then be served to every visitor, or an AVIF can reach a client that can't decode it.

If you add a layer in front of an image CDN, either pass Vary: Accept through and key the cache on it, or let the original CDN handle images directly.

A quick checklist

Request your main product or hero image with a browser Accept header. Note the Content-Type and size.
Request it again without one. If both match, the server doesn't negotiate, and the format you uploaded is the format everyone gets.
Look for Vary: Accept on negotiated responses.
Try more than one width. The format can change with size.
When an audit flags a heavy image, check which Accept header it sent before trusting the number.

If you'd rather scan a whole page than individual URLs, our website image auditor requests the page's images with a current browser's Accept header and shows the type and size it actually got.

This post was drafted with an AI assistant. Every command and output above was run against the live URLs shown, on 2026-10-12.