A client wants to use a WeChat-saved product image as a large detail image and add the original after launch—should we push back?

When product images look blurry after being uploaded to an official website, most cases are not caused only by the backend “compressing too hard.” More often, three problems occur at the same time: the source image dimensions are insufficient, the display slot does not match the device pixel density, and compression parameters stack up. Based on typical 2026 delivery experience, the source image short edge should be no less than twice the display width, product listing images should be about 100–300KB each, and large detail images about 300–800KB (experience range), with original assets kept for rollback. For most corporate official websites, this is visually sufficient on common phones and computers. Conversely, if the source image is only a few hundred pixels, no backend parameter adjustment can save it; the right move is to replace the asset or change the layout.

1. First identify which kind of blur it is, then decide what to change

In delivery communication, “blurry” is a broad term. On the page, it actually falls into three categories, with different locating methods and different fixes. Classify before acting; this can save a round of pointless parameter tuning and back-and-forth confirmation.

• Stretch blur: the image is enlarged, edges become fuzzy, and text shows ghosting; this is common when a full-width banner uses a small image saved from a WeChat official account article.
• Compression blur: the main outline remains, but blocky color patches or banding appear in gradient areas; this often happens after the quality value is set too low and the image is repeatedly resaved.
• Resize blur: the original is large but crammed into a small card; file size is wasted and details are resampled by the browser, which can look dull instead.

Judgment order: open the image alone in a new tab and view it at original size. If the file itself is clear but the page looks blurry, the issue is in the display slot or scaling; if the file itself is blurry, do not tune parameters—replace the asset first. This step is often skipped, and the result is that the client pushes for backend changes while the actual fix is the front-end container width or the asset itself.

2. Sharpness is determined by three layers: source image, display slot, and encoding

All three layers must align; miss one and the whole image effort is wasted. In typical 2026 projects, rework often happens not at the encoding layer but at the source layer, because assets are supplied by marketing or sales, sources are mixed, and no one can clearly state the original dimensions.

• Source image layer: the short-edge pixels are recommended to be no less than twice the display width; full-width slots often need source images above 2400–3000px (experience range), and 2x images are meant to cover high-DPI screens.
• Display slot layer: the container width hard-coded in CSS must match the actual rendered width; product cards stretched by flex layout and then enlarged again by the image is a common delivery pitfall.
• Encoding layer: JPG suits photos, PNG suits icons that need transparency, and WebP and AVIF have advantages in image quality at the same file size; but when the source image is insufficient, changing format is equally ineffective.

In other words, format only determines “who looks better at the same file size,” while dimensions determine “whether there are details to see”; the two cannot substitute for each other. Treating format conversion as a cure for blur is a common misjudgment in acceptance discussions.

3. Three common approaches: cost and timeline comparison

The choice depends on the number of images, the number of display endpoints, and how often images will be changed later—not on whether the backend has a particular switch. The three tiers below are ranges based on 2026 project experience and can be used directly with clients to discuss cost and timeline.

• Direct original-image upload: fast to launch and no extra configuration, but first-screen size often reaches several MB, making the first open noticeably slower on weak networks; suitable for intranet preview or temporary demos, not recommended as a formal launch practice.
• Unified compression on backend upload: simple to implement, with one image working everywhere; additional work is usually half a day to 1 day (experience range). The cost is that large detail images and list thumbnails share one quality level, often resulting in blurry lists and oversized large images, with manual fixes later.
• Generate multiple sizes by display slot: requires defining an image slot list and spec table upfront; the delivery timeline is usually 1–3 days longer (experience range). Images can be changed later without retuning parameters, balancing sharpness and file size; suitable for corporate sites with many product images and multi-end display.

A verifiable comparison: the same source image with a 900px short edge placed into a 1600px-wide detail slot will look soft after enlargement whether quality is set to 80 or 95, and whether converted to JPG or WebP. Conversely, a 2400px source image downsized to an 800px display slot at around quality 80 usually shows no visible difference on mobile. This shows that what needs changing first is dimensions, not parameters.

4. At the delivery site: handling a rush launch for large detail images

In one redesign, the main detail images supplied by the client’s marketing department were saved from WeChat official account articles; they were only just over 900 pixels wide, but the client wanted them to fill a 1600px-wide detail slot, and only three days remained before launch. The constraint at the time was that replacement images required the client to reshoot or find the originals, and the timeline could not slip further. The approach was to first list the display width of every image slot, work backward to minimum dimensions at 2x, and send that to the client; slots that could not be filled in the short term were changed to side-by-side text-and-image layouts instead of full-width hero images. After upload, five images were spot-checked on mobile. As a result, total first-screen image size dropped from a typical 3–6MB to around 1MB (experience range); the cost was one re-layout of the detail page and about half a day of extra communication, which avoided rework after launch.

5. Where it applies and where it does not

Suitable for multi-size processing: corporate official websites with many product images, needing to cover both desktop and mobile, and where non-technical colleagues will replace images later. Once the spec table is set, long-term rework is minimized.

Not necessary or not appropriate: text-only official websites, sites with only a few team photos, or assets that are themselves screenshots from the web or images resaved from chat records. In these cases, multiple specs offer limited benefit; replacing source images with qualified assets is more cost-effective. Images only for internal backend viewing also do not need multiple sets based on front-end display slots.

Standalone excerpt boundary: when the source image short edge is less than 1.5 times the display width, adjusting compression parameters cannot restore detail; at that point, change the layout or obtain new assets instead of continuing to try backend parameters.

FAQ

The client says to launch first and add original images later—can we agree?

You can agree, but specify the replacement time and the responsible person in writing, and list the homepage banner and first detail image as priority replacements; leaving low-resolution images up for a long time can hurt inquiry trust.

If the only source images are phone photos, can they go directly on the detail page?

Most can be used if lighting is sufficient and the short edge is about twice the display width; if noise is obvious, apply light denoising first; for full-width hero images, reshooting is recommended.

Is a backend quality value of 90 enough for sharpness?

No single value can settle it. When list thumbnails and large detail images share one value, the common result is blurry lists and oversized large images; tiered settings by image slot are more reliable.

Will switching to WebP make images sharper?

Not necessarily. Format mainly affects image quality and file size at the same size; when source dimensions are insufficient, changing format cannot restore detail and only reduces file size.

The client says it looks clear on mobile but blurry on desktop—why?

Commonly only one small image size was provided, and the desktop container widens it, causing a second enlargement; first check the ratio between display slot width and source short edge, then decide whether to replace the image.

If the official website is being redesigned or images are being replaced, two things can be done first: list all image slots across the site and mark their display widths, then check existing source images against “display width × 2.” This applies to corporate sites with many product images and multi-end display; it does not apply when the assets themselves are unqualified or the whole site has only a handful of images—for those projects, replacing source images first is more effective than adding processing steps.