Inspect the launched page's image request before changing component settings. Replace an insecure image address with a valid HTTPS endpoint or supported same-origin route, then check redirects, authentication, response content and the actual runtime source.
If an image appears in an editor but disappears when you launch an HTTPS page, inspect the browser request before changing the image component. An absolute http:// image address remains insecure even when the page that contains it uses HTTPS. The browser may upgrade that request to HTTPS or block it, depending on the request and its security policy.
Opening the image address in a separate tab does not prove that the secure page can embed it. This diagnosis concerns a browser-rendered page, the distinction explained in what to know about a web page signage player. Start with the launched page's Console and Network panels.
Match the symptom to the request
Use the browser's evidence to choose the next check:
- A mixed-content warning appears: The secure page references an insecure resource. Check the exact image address and whether the browser upgrades or blocks it.
- The browser tries HTTPS, but the image service fails: An automatic upgrade may have exposed an endpoint that cannot serve the image securely. Check the certificate, connection and requested path.
- No image request appears: Look for a security block in the Console. If there is none, inspect the component's evaluated source and whether the component is rendered.
- The request uses an unexpected host or path: The runtime value or relative URL resolution differs from the address you intended.
- The request redirects to a login page: The embedded request does not have the access context needed to retrieve the image.
- The response succeeds but contains a web page: The endpoint returned something other than image data, possibly with a successful status code.
- The response preview contains the correct picture: Move to component visibility, dimensions and layout rather than changing transport security.
An editor preview and a launched browser page can use different addresses, sessions and security rules. The launched page's request is the one that matters.
Capture the launched page's actual request
Open developer tools in the browser showing the affected page. If the deployed browser has no accessible developer tools, reproduce the issue in a supported desktop browser using the same public page address and intended access method. Confirm the result on the deployed browser afterward.
- Open the Network panel before reloading the page.
- Filter requests by the image filename or resource type. Remove the filter if nothing appears.
- Read the Console for mixed-content, certificate or content-policy messages.
- Inspect the image request's full URL, status and redirect chain.
- Record the final destination and inspect the response preview or body.
- Compare the request with the image source evaluated by the launched component.
Record enough detail to distinguish the initial URL from the final URL. A secure-looking starting address can redirect somewhere else. An insecure starting address may be upgraded before the browser sends a network request.
Do not share session cookies, authorization headers or signed URL tokens when collecting diagnostic information. A screenshot of an error can expose more than the image path.
Replace the insecure image route
The durable fix for mixed content is a valid secure route to the image, not a weaker browser configuration.
Take the exact runtime image address and check whether the image service supports the corresponding HTTPS endpoint. Keep the intended host, path and query parameters. Confirm that the browser accepts the certificate without an exception and receives the expected image.
If that endpoint works, update the source configuration or the data that supplies it. When the address comes from JSON, correct the relevant JSON field or its transformation rather than patching only one component instance.
Reload the launched page and inspect the request again. Confirm that it now starts with HTTPS and that no redirect sends it back to HTTP.
Use a supported same-origin path when appropriate
For an image that belongs with the application, the application's documented static-asset hosting method may be the simpler route. A root-relative source such as /media/notice.jpg uses the launched page's scheme, host and port. On an HTTPS page, that request therefore starts with HTTPS.
The leading slash means the public origin's root, not necessarily the application's folder. A reverse proxy may expose the application under a path prefix, and its routing must also make the image available. Verify the public URL before changing the component.
Use a supported asset location and publishing procedure. Do not place files in application installation directories merely because a similar deployment exposes them there. Include the asset and route configuration in backup and upgrade planning.
If the separate image service cannot provide HTTPS, ask for an approved secure hosting route or a narrowly configured reverse-proxy route. Do not create an unrestricted proxy that accepts arbitrary destination URLs. Do not disable browser security or make a protected resource public just to remove the symptom.
Separate origin rules from image permissions
Two services running on one computer do not necessarily share a browser origin. An origin consists of the scheme, host and port.
Compare the launched page address with the image's final address:
- A different scheme changes the origin and may introduce mixed content.
- A hostname, alias and IP address can represent different origins even if they reach the same machine.
- A different port changes the origin even when the scheme and hostname match.
However, a different origin does not automatically mean that ordinary image display needs permissive cross-origin resource sharing, or CORS, headers. A normal image element can often display a cross-origin image without them. Script-based retrieval and some uses of image data have different requirements.
Investigate CORS when the browser reports a CORS error or the application explicitly fetches the image through script. Do not add broad access headers just because two addresses differ.
A content security policy can independently restrict image sources. If the Console names an image-source policy violation, use the reported directive and blocked address to locate the relevant configuration. Add only the intended source through the application's supported security configuration.
Frame restrictions concern embedding documents inside frames. They are not the first place to look for a missing image element. Changing frame settings without a matching browser error leaves the image request unexplained.
Check runtime values and response bytes
A working address copied from a data file is not proof that the component uses that same address after launch.
Inspect the evaluated source value. Check for:
- Selection of the wrong JSON field.
- An empty value while data is loading.
- Quotation marks included as part of the value.
- Surrounding whitespace or incorrectly encoded characters.
- A relative path resolving against an unexpected base URL.
- An outdated hostname or a query token that has expired.
Then inspect what the request returns. A successful response status alone does not establish that the body contains an image. Check the response content type and preview. A login form, access-denied page or application error cannot serve as the expected picture.
Authentication can explain why direct navigation succeeds while embedding fails. The separate tab may have an existing session, while the embedded request receives different cookie treatment or follows a different hostname. Correct the intended access method rather than removing protection from the resource.
If the response contains image data but the browser cannot decode it, continue with signage image file troubleshooting. That is a file-content problem, not evidence that browser security should be relaxed.
If the preview shows the correct image, inspect the component's actual dimensions, visibility conditions, clipping and surrounding layout. At that point, changing HTTPS settings is unlikely to help.
Confirm the fix on the deployed display
Check the result using the actual launch address and intended access method, not only the editor preview or a separate image tab.
- Reload the page and confirm that the expected image appears.
- Confirm that the image request uses the intended secure route throughout its redirects.
- Check that the response contains the intended picture rather than a cached login page or error response.
- Confirm that the Console has no related mixed-content or image-policy error.
- Repeat the normal launch sequence on the deployed browser without relying on a temporary certificate exception or a diagnostic security setting.
Keep unrelated symptoms separate. If the entire display loses power or restarts, investigate the installation using the DC power wiring guide; changing an image URL will not correct a supply problem.
If the requirement is only to show prepared images and video rather than a live web application, an offline signage player offers a different content workflow. It is not a repair for the web page. For the browser-based page, the fix is complete when the runtime source, secure request, access permissions and returned image all agree.
Questions
Why does the image open directly but disappear inside the HTTPS page?
A separate tab uses a different loading context. It may permit navigation to an HTTP address or already have an authenticated session. An HTTPS page embedding that address must also satisfy mixed-content rules, content policies and the resource's access requirements.
Does using the same server prevent a mixed-content image error?
No. An absolute image address beginning with HTTP retains its own scheme even when both services run on the same machine. Compare the actual URLs, including scheme, hostname and port, then check the browser's security message and redirect chain.
Should CORS headers be the first fix for a missing image?
Not automatically. Ordinary image elements can often display cross-origin images without permissive CORS headers. Investigate CORS when the browser explicitly reports it or when script-based image retrieval requires it. Mixed content, content security policy and authentication are separate checks.
Can a root-relative image path avoid an absolute HTTP address?
Yes, if the application supports hosting the image at that public path. A root-relative address inherits the page's scheme, host and port. Confirm that the route returns the image through any reverse proxy and use the application's documented asset-publishing method.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.