A downloaded image may open as a web page because the saved file contains HTML from a sign-in screen, an expired download response, or an error page. Check the file’s actual contents with a trusted local viewer or file identification utility. Renaming an HTML file to PNG cannot turn it into an image; you need to retrieve the actual image data.
Identify what the download actually contains
A filename describes what a file is called. Its signature—the identifying bytes inside it—helps reveal what it contains. A PNG has a recognizable binary signature; an HTML document often contains readable markup such as <!DOCTYPE html> or <html>. Some image formats require a file identification utility for a dependable check.
Start with a trusted local image viewer. If it cannot decode the file, use a trusted local utility to identify its format. A plain text editor can reveal HTML, but avoid saving changes and do not execute unfamiliar content. An image viewer failing by itself does not prove the file is HTML: damaged or unsupported images can also fail.
First checkpoint: if the contents identify as HTML, stop image conversion attempts. If they identify as an image, investigate format support or corruption instead.
Where your browser provides download or network information, examine the response’s Content-Type. text/html supports the explanation that a page was returned; an image type should correspond to the expected image format. Servers can mislabel responses, so compare this information with the file contents.
Retry from the authenticated result
A download can lead to a page when a session has ended or a temporary address is no longer valid. This is a possibility to investigate, not a diagnosis based solely on the filename.
- Keep the suspect file unchanged and note its name and approximate download time.
- Sign in through your normal Imagild session and reopen the relevant task or result, if it remains available.
- Use the currently available download action from that result. Check the interface rather than assuming a particular control exists.
- Save the new file separately, identify its actual format, and open it in a trusted image viewer.
- Compare the decoded image with the intended result, including the subject and crop.
Second checkpoint: a working preview paired with an HTML download points toward a retrieval problem. If the result itself shows an error or is unavailable, repeated saving of the same response will not restore the image.
Format conversion belongs in an external editor only after you have a decodable image. Conversion cannot recover pixels from a sign-in page.
Fictional planning scenario: Mira’s ceramic bowl image
In this fictional planning example, Mira expects a bowl photograph but receives a file named bowl.png that opens as a page. Her acceptance checks are observable: a local utility identifies image data, a viewer displays the bowl, and the crop matches the intended result.
Mira plans to compare the suspect file with a fresh download made while signed in. If the fresh file still contains HTML, she records the task ID, timestamp with time zone, and a short description of the visible error for a private support request.
Third checkpoint: before sharing evidence, remove signed download addresses, access tokens, and account details from screenshots or copied messages. Keep diagnostic identifiers private; do not post the entire response or browser network log publicly.
Questions about misleading downloads
Will changing the extension fix it?
Only if the contents already contain a valid image with the wrong extension. HTML renamed to PNG remains HTML.
Does Content-Type prove the format?
No. It is useful evidence, but the file signature and successful image decoding provide stronger confirmation together.
What should I keep for support?
Keep the task ID, timestamp, filename, detected format, and concise error description privately. Share through an appropriate private support channel without signed URLs or tokens.