Seeing a photograph in a browser editor does not prove that the page may read its pixels back into a downloadable file. A remote image can display normally yet make an HTML canvas ineligible for export. If the reported error is a canvas SecurityError, investigate the image-loading route before paying to generate the picture again. A silent download button alone is not enough to establish that diagnosis.
Separate showing an image from reading its pixels
MDN's cross-origin image guide explains that drawing foreign-origin image data without the necessary CORS approval taints a canvas. This is a browser security boundary, not an artistic defect in the photograph. An image opening successfully in its own tab does not establish permission for another page to read back a composition containing it.
Ask which operation failed: loading the source, drawing the composition, exporting the canvas, or saving an already-created file. Those are different checkpoints. Preserve the editing project and record the exact visible error. If a downloaded file already exists but contains a login page, investigate that retrieval problem separately rather than calling it a tainted canvas.
Build a harmless two-input comparison
Use a duplicate project and an image you own. Prepare one small, decodable local image through the editor's supported upload control. Separately, record the remote input that was added before export failed. Do not delete the only working composition or replace the customer's approved picture to make a button work.
| Copy to inspect | Observation to record |
|---|---|
| Fresh project with permitted local image only | Does normal export produce a decodable file? |
| Copy after adding the remote image | Is the same export blocked with a canvas security error? |
| Delivered export after an approved repair | Are the required image, crop and dimensions retained? |
This is a proposed diagnostic exercise, not a browser experiment performed for this article. A difference between the first two copies helps locate the failing input route. It does not establish that every failure after a remote upload has the same cause. Some editors export on a server and follow a different architecture.
Choose a supported route instead of changing the picture
If authorized, obtain the actual source file through its normal download route and import it using a supported file upload. Alternatively, the service operator can provide a properly authorized image-loading path. The client request and source server must cooperate; typing a CORS option into a prompt cannot grant that permission.
Keep private references private. A public image proxy, a shared account token or disabling browser protections is not a routine export fix. Ask the operator which supported route preserves the reference's access restrictions. Rebuild the comparison through that route; painting over a previously drawn image is not evidence that the canvas became readable again.
Send a reproducible support brief
In a project copy, an authorized local image exports, but adding this remote reference produces the recorded SecurityError during export. Preserve the approved composition. Check the input request and permitted image response; do not submit another generation. Verify the repaired download opens as an image and contains the expected crop and dimensions.
MDN's toBlob reference documents the export exception. Share only a sanitized error, project identifier and non-sensitive source host privately; exclude signed addresses and tokens. For work developed with Imagild Skills, check the actual editor and its supported import controls. This guide does not establish that Imagild currently has this defect or exposes browser configuration. Accept the repair only after the intended composition exports and the received file is inspected.