Check the browser's actual image request before changing permissions or reimporting assets. Compare the managed-resource route, evaluated source and server response, then correct one component and verify it in a fresh authorized session.
Start HMI image path troubleshooting with the URL the browser actually requests, not with server folder permissions. After a migration, an unchanged image source can resolve against a different hostname, application path or managed-resource route. The image may exist on the production server while the browser requests the wrong address. Capture one failed request, compare it with a working managed-image request, and correct the smallest confirmed difference before replacing assets or changing access rules.
What the symptoms point to
Use the pattern of failure to choose your next check:
- Every managed image fails in the browser, but another client displays them: investigate browser-facing routing, source construction and authentication first. The working client shows that the resource is retrievable through that client's access path, not that every browser route is correct.
- Only one image fails: check its exact resource name, capitalization, extension and deployment status before changing shared settings.
- Images work in development but fail in production: compare the resolved request URLs, application base paths and any reverse-proxy routing. Matching folder trees do not establish matching runtime addresses.
- A direct image request works, but the component still fails: inspect bindings, generated source values, browser policy errors and the response the component actually receives.
- The correct image appears but is cropped or hidden: investigate component dimensions, scaling and layout rather than resource permissions.
A broken-image icon identifies a failed display result. It does not identify the cause. Keep changes away from machine-control logic, and use an approved maintenance process if missing graphics make operating status ambiguous.
Separate the resource name from its web address
A managed image has several identities that can look deceptively similar: its name in the resource manager, the component's source property and the URL requested by the browser.
The resource manager may present a folder hierarchy without exposing ordinary operating-system folders. Some HMI platforms store managed images in a database or another application-controlled store. Check the manufacturer's documentation before treating that hierarchy as a disk directory.
The browser still needs an address served by the application. That address may include a managed-image route that does not appear in the resource's displayed name. A copied folder label can therefore be correct as a resource identifier but incomplete as an image source.
Relative references also depend on context. A path without a leading slash can resolve relative to the current page. A path beginning with a slash resolves from the web origin's root, which may be wrong when a reverse proxy places the application beneath another path. A complete URL fixes the origin explicitly but may introduce deployment or browser-security problems.
Do not choose one form by habit. Use the source format documented for your HMI component and confirm the resulting production request. HTTP URL paths use forward slashes; a desktop-style folder path is not a substitute for the documented web route.
Capture the failed request before editing
Choose one affected image in a controlled view. Record its configured source and, if a binding or expression supplies it, the evaluated runtime value. A correct-looking design-time value does not prove that the runtime binding emits the same string.
Open the browser's developer tools and select the Network panel. Reload the view with recording enabled. Select the failed image request and inspect its URL, status, redirects, response headers and response content. Check the Console panel for browser blocking messages as well.
| Request result | What it suggests | Next check |
|---|---|---|
| No image request appears | The component may have an empty source, a failed binding or rendering logic that prevents loading | Inspect the evaluated source and component visibility |
| 404 response | The route or resource was not found | Compare the documented route, resource identity and proxy mapping |
| 401 or 403 response | Authentication or authorization needs investigation | Check the supported session flow, application roles and server logs |
| Redirect to a sign-in page | The request may not have the expected authenticated session | Inspect the redirect chain within the intended browser session |
| 200 response containing HTML | A login page or fallback page may have answered instead of an image | Inspect the response body and content type |
| Browser blocks the request | Mixed content, content policy or another browser restriction may apply | Read the exact Console message before changing configuration |
| Image bytes arrive but decoding fails | The file may be damaged, unsupported or served incorrectly | Check the format, response content type and actual image data |
A 404 is not proof that the image is absent. Likewise, a 403 is not proof of an operating-system permission problem. Interpret the response together with application and proxy logs.
When sharing diagnostics, remove session cookies, authorization headers and sensitive query values. Do not copy an authenticated request into an unrelated service.
Compare equivalent requests on both servers
Use the same component and intended managed image on development and production. Compare these details rather than just the visible folder labels:
- The configured source and its evaluated runtime value.
- The request scheme, hostname, port and application path.
- The managed-resource route preceding the image name.
- Folder names, filename capitalization and URL encoding.
- Redirect destinations and response content types.
- The application version and documented resource-serving behavior.
Obtain a working reference through the platform's documented image selector or a known working component on the same production deployment. Compare the request it generates with the failing request. Do not guess a resource endpoint from a different installation.
If another client displays the same managed image, treat that as useful evidence, not a complete browser test. Different clients may use different resource APIs, sessions or permissions. It narrows the investigation without proving that the browser-facing delivery path works.
Also distinguish project deployment from resource deployment. Depending on the platform, copying a project may not copy every managed resource or server-level setting. Confirm the intended image exists in the production resource store through the supported administration interface.
Apply the smallest supported correction
Once the request comparison identifies the fault, change one noncritical component before updating shared templates.
- Preserve the original source and binding so the change can be reversed through the normal project workflow.
- Correct the source construction to use the manufacturer's documented managed-image route and the intended resource name.
- If a binding assembles the address, fix that binding rather than overriding only its displayed result.
- Publish the controlled change and reload the view.
- Confirm that the browser now requests the intended resource and receives decodable image content.
- Apply the confirmed correction to other affected components, then review their generated requests individually.
If the measured fault is authorization, use the documented role or session configuration. Do not make the resource store public, broaden filesystem permissions or disable browser protections as a diagnostic shortcut.
Reimport an image only when evidence shows the resource is missing, damaged or incorrectly deployed. Replacing a valid image does not repair an incorrect request route, and it adds another variable to the investigation.
Check the result in a fresh session
Verify more than the disappearance of the broken-image icon. Confirm that the displayed graphic is the intended resource, especially where images represent equipment state.
Open a fresh authorized session and revisit each affected view. Check several images, including resources in different managed folders. Confirm their runtime source values, request addresses and responses. If caching obscures the result, use the browser's diagnostic cache controls during the check rather than assuming that an old display proves the deployed change works.
Also check navigation between views. A relative source can work on one page and fail after navigation changes the address context.
If the resource loads correctly but its visible area is wrong, move to diagnosing kiosk browser sizing in an HMI window. That is a layout investigation, not an image-route repair.
Close the change record with the original symptom, the observed request difference, the corrected source rule and the verification results. That makes the next migration a configuration comparison rather than another round of permission changes.
Questions
Does a broken HMI image mean server permissions are wrong?
No. A broken-image icon can result from an incorrect URL, a missing managed resource, an authentication response, browser blocking or an unreadable image file. Inspect the browser request and response first. Change filesystem permissions only when the documented storage arrangement and server diagnostics identify them as the cause.
Why can the same image source work in development but fail in production?
The same source string can resolve differently when the hostname, application base path or reverse-proxy configuration changes. Development may also use different resource-serving behavior. Compare the evaluated source and complete browser request on both deployments rather than relying on matching resource-manager folder names.
Should managed images be reimported after a migration?
Only when checks show that the production resource is missing, damaged or incorrectly deployed. If the server already holds the correct image but the browser requests another route, reimporting does not address the fault. Correct one component's documented resource reference and verify its request before changing shared templates.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.