DEV Community: pgodace

Your product photos get rejected for file size, not resolution

pgodace — Tue, 27 Oct 2026 19:35:49 +0000

Marketplaces reject product photos far more often for file size than for dimensions, and almost nobody documents the ceiling next to the pixel size. I compiled the published upload rules for 18 marketplaces into one file, and the volume constraints turned out to be the most hostile part of it.

Here is what those numbers actually look like, and a way to stop guessing which quality setting fits.

Only 13 of 51 rules publish a cap — and they disagree by 640×

Across the 18 platforms I checked, there are 51 separate rules (main image, zoom, detail, banner, video cover…). 38 of them state no file-size ceiling at all. The 13 that do use 7 different numbers:

Platform	Slot	Pixels	Ceiling
Pinduoduo	order thumbnail	200×200	32 KB
Pinduoduo	home banner (white bg)	750×352	100 KB
WeChat Store	main	600×600	1024 KB
Pinduoduo	main	800×800	2048 KB
Kuaishou	main (white bg)	800×800	2048 KB
Temu	carousel (white bg)	800×800	2048 KB
Shopee	main	800×800	2048 KB
Pinduoduo	SKU	480×480	3072 KB
Douyin	main	600×600	5120 KB
Douyin	main (white bg)	800×800	5120 KB
Douyin	detail	750×1000	5120 KB
Shopify	main	2048×2048	20480 KB
Shopify	main (max)	5000×5000	20480 KB

32 KB → 20480 KB is a 640× spread. The photo that sails into Shopify as a 5000×5000 PNG will be bounced by Pinduoduo's 200×200 thumbnail slot unless it is under 32 KB.

Two combinations are genuinely nasty:

Pinduoduo's 750×352 home banner: white background and ≤ 100 KB. A wide white-background JPEG that small is a compression exercise, not a crop.
The 200×200 thumbnail at 32 KB: I measured this one instead of guessing, and it is the opposite of what I expected — see the numbers below. The cap is not tight for simple images; it is tight for busy ones, and a real product photo is busy.

I measured it instead of guessing

I took a 3000×2250 test image, resized it to the constrained sizes above, and encoded it as JPEG at six quality settings in Chrome:

Output size	q .95	q .90	q .80	q .70	q .50	q .30
200×200	8.4 KB	5.9 KB	4.3 KB	3.8 KB	3.0 KB	2.4 KB
750×352	29.0 KB	18.4 KB	12.8 KB	10.4 KB	6.6 KB	5.4 KB
800×800	56.7 KB	33.6 KB	20.9 KB	15.5 KB	11.7 KB	9.5 KB
750×1000	64.3 KB	38.5 KB	24.0 KB	18.2 KB	13.5 KB	11.0 KB

Read the caveat before you reuse these numbers: my test image is synthetic colour gradients, which compress much better than a photograph. Fabric weave, wood grain, food texture, printed text — the things product photos are made of — cost several times more bytes at the same size and quality. So treat this table as a floor, not an estimate for your catalogue.

That reframes the 32 KB slot honestly: at 200×200 even quality 0.95 produced 8.4 KB here, so the ceiling is not absurd on its own. What makes it dangerous is that the same quality setting on a real, textured photo can be an order of magnitude larger — and you only find out at upload time.

Why "export at quality 80" doesn't solve this

File size is roughly pixels × bits-per-pixel. Resizing changes the first term by the square; quality changes the second by 3–6× across the whole usable range (measured above: 56.7 KB → 9.5 KB from q .95 to q .30 at 800×800). So:

Going 4000×3000 → 800×800 cuts pixel count by ~19×. That is the big lever.
Going quality 0.95 → 0.50 saves roughly 3–5×, and starts to be visible on product edges and fine text.

If you pick one quality for everything, you are choosing the second lever only, and you will either ship 3 MB files that fail the 100 KB slot, or crush every image to satisfy the single tightest ceiling you happen to have.

What actually fits: downscale first, then search the quality

The honest algorithm is two steps, and the second one is a search, not a guess:

Resize so the image is exactly the required pixel size (never rely on the file size to imply dimensions).
If a ceiling exists, binary-search the encoder quality until the encoded bytes fit.

That is what my own pipeline does, and it is not clever — it is just measurement. The search runs between quality 0.30 and 0.95 with at most 8 encode attempts, taking the highest quality that fits:

// canvas -> Blob, then binary search on quality for a byte budget
async function encodeWithBudget(encode, maxBytes) {
  let lo = 0.30, hi = 0.95, best = null;
  for (let i = 0; i < 8; i++) {
    const q = (lo + hi) / 2;
    const blob = await encode(q);           // encode(q) -> Promise<Blob>
    if (blob.size <= maxBytes) { best = { blob, q }; lo = q; }
    else { hi = q; }
    if (hi - lo < 0.02) break;
  }
  return best;                              // null => even q=0.30 doesn't fit
}

Two properties matter more than the exact numbers:

It returns null instead of lying. If quality 0.30 still exceeds the ceiling, you must shrink the image or change the format — silently shipping an oversized file just moves the rejection downstream.
It never re-encodes more than ~8 times per image. With 51 outputs per photo you can feel an unbounded search loop on a phone.

For reference, an audit run of 15 outputs from my tool (200×200 up to 1000×2000, white-background and transparent slots mixed) produced JPEGs between 15 KB and 44 KB. That is under every ceiling in the table except the 32 KB thumbnail — and 32 KB sits inside that range, so whether an output passes depends on the image, which is the whole point.

A five-second check on your own folder

Before blaming the platform, see which files are over which ceiling. macOS / Linux:

find ./exports -iname '*.jpg' -size +2048k -exec ls -lh {} \;

Windows PowerShell:

Get-ChildItem .\exports\*.jpg | Where-Object Length -gt 2MB | Select-Object Name, Length

And if you want to know what a given pixel size can reach at all, measure the encoder instead of trusting a blog post:

// returns the smallest quality that fits, or null
const probe = async (img, w, h, maxBytes) => {
  const c = new OffscreenCanvas(w, h);
  c.getContext('2d').drawImage(img, 0, 0, w, h);
  return encodeWithBudget(async (q) => c.convertToBlob({ type: 'image/jpeg', quality: q }), maxBytes);
};

The part nobody documents

The 38 rules without a published ceiling are not permission to upload 40 MB. In practice they mean "the platform will re-encode your file and may reject it if it is absurd". I kept them as maxKB: null in the dataset rather than inventing a number, because a made-up limit is worse than a missing one.

Same for the white-background slots: 16 of the 51 rules require a white background, and "white" means the pixels, not the intent. In my own test images the "white" sweep of a photo-style shot measured 246–252 on all three channels — visibly white on screen, and not white to a checker that wants 255. If your pipeline only fills the letterbox padding with white, you will fail these slots even though the image "looks white".

Where the data lives

The full set — 18 platforms, 51 rules, a maxKB (or explicit null) and a sourceUrl on every rule:

JSON: https://tugui.top/data/specs.json
CSV: https://tugui.top/data/specs.csv
npm: npm install tugui-specs
mirror: github.com/pgodace/tugui-specs-data, MIT

25 of the 51 rules trace to the platform's own documentation, 26 only to third-party write-ups — each rule says which. If a ceiling has changed, send me the URL and I will fix it.

I also build the tool that produced the measurements in this post: it resizes one photo into every marketplace size in the browser, nothing uploaded (tugui.top). Five files per batch free, $4/month or $12/year. The dataset is useful without it.

One product photo, twelve required sizes: what 18 marketplaces actually demand

pgodace — Tue, 27 Oct 2026 16:57:23 +0000

I build a small tool that resizes product photos for marketplace listings, and the hard part was never the resizing. It was answering one question 51 times: what exactly does this platform require?

Those requirements live in help-center pages, seller forums, and blog posts — often in Chinese, often contradictory, sometimes just a screenshot of a table. So I turned them into one file, with the URL each number came from, and published it. Here is what the data looks like, and where it is softer than it appears.

The shape of the problem

18 platforms, 51 rules. A platform usually has more than one rule, because the main image, the zoom image, the detail image and the video cover are separate requirements:

Taobao 2, JD 3, Pinduoduo 4, Douyin 3, Kuaishou 2, 1688 2, WeChat Store 1, Youzan 14
Amazon 3, Walmart 4, Shopify 3, eBay 2, AliExpress 1, Temu 1, Shopee 1, Lazada 1, Shein 3, TikTok Shop 1

51 rules, but only 29 distinct pixel sizes. And one size dominates: 800×800 appears in 12 of the 51 rules. After that: 200×200 (4), 750×1000 (3), 600×600 (3), 100×100 (3), 1000×1000 (2).

The file-size ceilings are worse than the pixel sizes. Only 13 of the 51 rules publish a cap at all, and those 13 use 7 different numbers spread over three orders of magnitude: 32 KB, 100 KB, 1024 KB, 2048 KB (4 rules), 3072 KB, 5120 KB (3 rules), 20480 KB (2 rules). A photo that passes one platform's cap gets rejected by another for being 30× too large — and the rejection message usually doesn't say which limit it hit.

The other 38 rules simply don't state a maximum. That's a real property of the data, not an omission on my side.

Formats in the dataset: jpg, jpeg, png, and mp4 for the video-cover rules.

A rule looks like this

{
  "id": "white-800",
  "slot": "main",
  "width": 800,
  "height": 800,
  "aspect": "1:1",
  "minWidth": 800,
  "maxKB": null,
  "background": "white",
  "formats": ["jpg", "png"],
  "sourceUrl": "https://…"
}

maxKB: null means the source didn't publish a ceiling, not that anything is allowed. background is one of white, transparent, any — 16 of the 51 rules require white, which turns out to be the single most under-rated field in the whole file (more on that below).

What "verified" honestly means

Of the 51 rules, 25 point at the platform's own documentation and 26 only at third-party write-ups — seller blogs, agency guides, forum posts. Every rule carries its sourceUrl and every platform carries a homepage, so you can recompute that split yourself against whatever list of official domains you trust. The site labels each rule accordingly instead of quietly presenting a blog post as platform documentation.

Two things I ran into while compiling it:

Sources disagree. For at least one platform, two seller guides stated different minimum sizes, and neither linked to the platform's own page. I kept the one I could trace and marked the kind.
"White background" is a trap. 16 rules ask for it. What they actually mean is 255,255,255; a product photographed on a light-grey sweep lands around 246–252 and fails review with no explanation. If your pipeline "fills the empty space with white" but never touches the photo's own background, you will still be rejected. I ended up adding a step that only rewrites near-white pixels when the image border is already ≥85% near-white, so it can't wreck a coloured background.

Machine-readable, not a blog post

The whole thing ships as data, so you don't have to scrape this article:

JSON: https://tugui.top/data/specs.json
CSV, one row per rule: https://tugui.top/data/specs.csv
npm: npm install tugui-specs
mirror with README and license: github.com/pgodace/tugui-specs-data
for agents: https://tugui.top/llms.txt and https://tugui.top/llms-full.txt

MIT for the dataset file itself. The platform names are their owners' trademarks; this is a convenience copy of publicly documented upload requirements, not an official API and not an endorsement.

What this dataset can't tell you

The numbers are the easy half. A marketplace review also looks at things no dataset can encode:

whether the product fills enough of the frame
whether there is a watermark, text, or a border
whether a human reviewer simply doesn't like the photo

I also built a checker that evaluates only the four hard numbers — pixel size, aspect ratio, file ceiling, format — and says so on the page. It never claims an image will pass review, because it can't know.

Why publish it

The tool resizes a batch of photos to any of these specs in the browser, one photo → every marketplace size, sorted into a folder per platform, with nothing uploaded (tugui.top). Five files per batch are free, a license is $4/month or $12/year — so yes, this post is also marketing.

But the dataset is useful on its own, and the interesting part of the work was the verification, not the product. If you find a number that's wrong, or a platform whose published requirement changed, open an issue on the mirror repo with the URL and I'll fix the rule and bump the date.

generatedAt in the file is the date the sources were last checked by hand — 2026-10-25 as of this post — not the date the JSON was regenerated.