How to Standardize Product Images for Marketplaces

01

Define consistency in catalog terms

Two images can both be 2,000 by 2,000 pixels and still look unrelated. One shoe fills 92% of the canvas while the next fills 55%. One chair sits on an implied floor line and another floats in the center. One product has a soft shadow while its neighbor has a hard gray rectangle from an old clipping path. Pixel dimensions are only the container.

Write those decisions in a one-page asset standard that merchandisers and developers can both read. If “centered” means one thing to the studio and another to the transform code, the product grid will become the negotiation surface. It is not an especially good one.

02

Put channel requirements in versioned profiles

Marketplace requirements are current facts, not universal constants. Do not hard-code a remembered dimension from a blog post into a worker and call it “Amazon mode” forever. Keep a profile for each destination, cite the official seller documentation in the profile record, note when it was checked, and review it on a schedule.

{
      "profile": "marketplace-primary-v4",
      "checkedAt": "2026-06-20",
      "sourceOfTruth": "official seller image requirements URL",
      "canvas": { "width": 2000, "height": 2000, "background": "#ffffff" },
      "subject": { "fit": "contain", "maxWidth": 0.86, "maxHeight": 0.86 },
      "output": { "format": "jpg", "quality": 92, "colorSpace": "srgb" },
      "limits": { "maxBytes": 8000000 },
      "allowed": { "text": false, "watermark": false, "border": false }
    }

03

Create a reusable master before channel derivatives

Keep the original source and create a high-quality transparent master or alpha mask at the best useful resolution. The master should preserve the full subject, meaningful internal openings, and any approved shadow treatment. Avoid resizing it down to the first channel's output size; derivatives can become smaller, but they cannot recover chain links or hair that were discarded upstream.

Store source checksum, master checksum, processor options, recipe version, and product identity. If a marketplace updates its minimum dimensions or the merchandising team changes product padding, regenerate derivatives from the master. Re-running background removal should be a deliberate model or quality decision, not the default response to every canvas tweak.

04

Normalize subject geometry by category

A single “fill 85% of the square” rule works until the catalog contains fishing rods, earrings, sofas, and six-packs. Normalize within product families. Use the visible foreground bounds to calculate scale, then apply category-specific maximum width, maximum height, anchor, and floor line.

Use foreground bounds carefully when a natural shadow is included. A faint shadow can expand the bounds and shrink the product. Measure the solid subject for scaling and composite the approved shadow afterward, or use separate alpha thresholds for subject and soft shadow. Otherwise one especially ambitious shadow can make a chair look like dollhouse furniture.

05

Make background, format, and color explicit

A transparent PNG displayed on a white page may look like a white-background image, but it is not the same publishing asset. Some feeds flatten transparency unpredictably or reject it. Some channels want a solid background for primary images while allowing different treatments elsewhere. Create the exact file required by the profile instead of relying on the destination to interpret it kindly.

Normalize to sRGB unless a destination explicitly requires something else. Preserve a source profile in the original archive, but do not let untagged RGB, CMYK JPEGs, and wide-gamut phone images wander into the same feed untreated. Color surprises are especially visible when product variants sit beside one another.

06

Standardize product identity and image sequence

Image standardization fails if the finished files cannot be matched back to products. Carry product ID, SKU, variant ID, source asset ID, view type, and sequence through the manifest. Do not reconstruct them from a renamed output after processing. The file name is a convenient label; the manifest is the relationship.

{
      "productId": "P-1842",
      "sku": "P-1842-BLUE",
      "variantId": "V-1842-BLUE",
      "view": "front",
      "sequence": 1,
      "sourceAssetId": "asset_f91a",
      "masterAssetId": "asset_a03c",
      "profile": "marketplace-primary-v4",
      "outputKey": "P-1842-BLUE/marketplace-primary-v4/01-front.jpg"
    }

Sequence rules should be category-aware and should never erase a merchant's intentional merchandising without a review. The pipeline can identify missing required views and normalize assets; it should not decide that a close-up of an important clasp is less useful than the fifth nearly identical angle simply because the filenames sort that way.

07

Validate the file and the catalog meaning

Run machine checks before a derivative reaches the feed, then review the cases where machine checks cannot decide intent. Decode the final bytes, verify dimensions, format, color space, alpha policy, and file size, and scan the protected margin for clipping. Confirm that the manifest references a real product and that the view and variant belong to it.

Keep a rendered contact sheet for each batch. Reviewers spot inconsistent scale, floor lines, white balance, and accidental duplicates much faster in a grid than one file at a time. Randomly sample accepted batches after launch so a supplier or camera change cannot drift for months behind technically valid files.

08

Roll out one channel and category at a time

Choose one destination and one visually forgiving category. Generate derivatives in shadow mode, compare them to the current listings, and record rejection reasons. Tune subject scale and category exceptions before turning on publishing. Then expand to adjacent categories rather than applying the first successful shoe rule to sofas and necklaces.

Version every change. Keep old derivatives for a rollback window and know which live listings use each profile. A standard is successful when a rule change can be regenerated and compared before publishing not when someone finally finds the transform values in an old Lambda env var.