Why Can Shoppers See My Product Photo While a Browser Editor Cannot Export It?

Locate the failure after the image loads

Ask the editor's maintainer to distinguish an image-load failure from an export failure. If the picture never appears, investigate its response and loading error. If it draws successfully but export fails with SecurityError, canvas origin restrictions are a relevant branch to inspect.

MDN documents that drawing cross-origin content without CORS approval taints a canvas, preventing pixel-reading and export operations such as getImageData, toBlob and toDataURL. Successful visual display therefore does not establish permission to export that canvas.

Do not infer this diagnosis from a generic Download failed message. Obtain the actual browser error and identify the operation that failed. A server error, unsupported encoding request or application exception can produce a different problem with a similar user-facing message.

Match the image request to the hosting response

Record the editor's origin and the image's final origin, including any redirect. Origin includes scheme, host and port; a CDN address can differ from the storefront even when both belong to the same business.

For an approved public image, the maintainer should inspect whether the image was requested in the intended cross-origin mode and whether the server's CORS response permits that use. MDN's example sets the image's crossOrigin attribute before assigning its source. A response header alone does not establish that the application loaded the asset using the required request mode.

Keep the repair specific to the authorized asset and editor. If you do not control the image host, ask its owner for a supported asset-delivery route. Repeatedly converting the same remote photo between JPEG and PNG does not establish cross-origin permission.

Hypothetical comparison with a clean canvas

A fictional banner editor runs on the shop's origin and loads an approved bottle photo from a CDN. In case A, assume the image is loaded without the necessary CORS approval: it is visible, but the canvas export raises SecurityError.

In case B, the maintainer creates a fresh canvas and loads that approved photo with the intended request mode and a permitting server response. Suppose its export succeeds. This comparison supports the origin-access explanation under the stated conditions; it is not evidence that the live CartVisual editor has this defect.

Use a fresh canvas for the controlled rerun rather than continuing with an earlier tainted composition. Add other remote layers individually. A permitted product photo does not make a separate, unapproved remote logo safe to read from the same canvas.

Close with the actual exported asset

Once the permission path is corrected, export the intended composition and inspect the resulting file. Confirm that the correct product image, overlays and output dimensions survived. An export that merely stops raising an exception can still contain the wrong asset.

Keep a concise handoff containing the failed operation, image origin, request-mode finding and relevant server-response finding. Exclude private image URLs and authentication details from public bug reports. This gives the maintainer evidence for the actual delivery boundary without confusing a browser restriction with a damaged product photograph.

Record your own observations

The filled rows are illustrative examples. Use the blank row for your own files and observations.

Download the editable CSV worksheet

What the references establish

• MDN — Use cross-origin images in a canvas: Documents canvas tainting, restricted pixel/export methods and coordinating the image's cross-origin request with a permitting server response. The merchant comparison is hypothetical and no live editor was tested.