Retrieve FTP images on the server, then deliver them to the browser through an authenticated HTTPS endpoint or a supported data URI. Keep credentials server-side, bound each transfer and tie every displayed image to its inspection so delayed responses cannot show an older result as current.
An industrial dashboard cannot display an FTP image just because its image component accepts a URL. Current mainstream browsers do not fetch FTP resources natively. Move that retrieval to a gateway or server, then give the browser either an HTTPS image URL or a supported data URI containing the image bytes. Saving the download to the server's disk is not enough by itself. The browser still needs an authorized way to receive those bytes.
Why an FTP image URL stays blank
A browser-based dashboard separates the application server from the browser displaying the page. Setting an image source usually tells the browser where to fetch the image. It does not necessarily tell the application server to download it.
That distinction explains why a valid FTP address can leave an empty image box. The FTP server may be reachable and the file may exist, but the browser does not support the requested protocol. Adding credentials to the address or opening it through dashboard navigation does not add that support.
Cross-origin rules are a separate issue. They do not restore FTP support. An ordinary cross-origin HTTP image can often display without CORS permission, while scripted requests or reading its pixels through a canvas may require that permission. Content security policy, authentication and mixed-content restrictions can also affect HTTP delivery.
Diagnose the transport first. Do not change browser security settings to compensate for an unsupported image source.
Where image retrieval belongs
Put the FTP connection in a documented server-side facility provided by your dashboard platform, or in a separate service that you control. Confirm where the script actually runs. A browser script cannot use a server's FTP library simply because both belong to the same project.
The delivery path becomes:
- The application receives an inspection identifier or image request.
- A server-side process resolves that identifier to an allowed file.
- That process retrieves the completed image through the source's documented interface.
- The application sends the image to the browser through a supported delivery method.
The final handoff is the important choice:
| Delivery method | Useful when | Main constraint |
|---|---|---|
| Data URI in the image source | Images are small, occasional and short-lived | Encoding and session state increase memory and transfer size |
| Authenticated HTTPS image endpoint | Images refresh frequently or several sessions need them | The endpoint needs authorization, resource limits and cache rules |
| Retained image with an HTTPS delivery path | Inspection records need later review | Storage requires retention and access policies |
These are image-delivery methods, not functions of an offline media playlist. The distinction between a live factory data display and a signage dashboard matters before choosing the display application.
When a data URI fits
A data URI places the image content directly in the image source instead of pointing to a separate download. For a JPEG, its form is data:image/jpeg;base64, followed immediately by the base64-encoded image bytes.
The server retrieves the file as binary data, checks it, encodes it and assigns the resulting string through the platform's supported image API. No second browser request to an image server is needed.
Check these details before choosing this route:
- The dashboard component must explicitly support data URIs.
- The page's content security policy must permit the required image source.
- The declared media type must match the actual image format.
- The encoded payload must contain the file bytes, not a textual representation of a byte buffer.
- The application must enforce a maximum download size before accumulating an unrestricted response in memory.
Base64 encodes each group of three input bytes into four characters, with padding when needed. That makes the encoded content roughly one third larger before application-message overhead. Several sessions or frequent updates can multiply this cost.
Keeping the transfer in memory avoids deliberately creating another image file. It does not prove that no copy exists elsewhere. Application state, diagnostic captures or browser storage may still retain content. Do not log the encoded payload or claim that this method prevents all retention.
When an HTTPS endpoint fits
An HTTPS endpoint lets the browser request an image through a normal web address. The endpoint can retrieve an allowed source image, return a short-lived cached copy, or serve an image already collected by a background process.
Use the platform's documented web-serving extension or an approved application service. Merely downloading a file into a gateway directory does not publish it. Likewise, a server filesystem path has no useful meaning to a browser on another computer.
A same-origin endpoint often simplifies browser integration. It does not remove the need to authorize each request. Check that the requesting session may access the selected inspection image, and return the correct image content type.
Avoid accepting arbitrary FTP URLs or filesystem paths from the browser. Prefer an inspection identifier that the server maps to a configured source and directory. Restrict filenames and reject path traversal. Otherwise, an image feature can become an unintended route to internal servers or unrelated files.
For transient images, apply a deliberate cache policy. Sensitive inspection images may warrant Cache-Control: no-store. Where caching is permitted, a versioned URL can distinguish successive images without repeatedly fetching an unchanged file. Neither approach replaces application-level authorization.
How to handle images that change
A successful download does not necessarily mean the image belongs to the inspection currently shown. Treat image identity and image availability as separate requirements.
Use a stable inspection identifier, sequence value or documented filename rule to connect the image with its result. If the source repeatedly overwrites one filename, establish how the application knows that a new write is complete. A producer-side completion signal or write-then-rename workflow can help where the source supports it. A fixed delay alone does not prove completion.
Check the downloaded content before displaying it. Reject empty files, enforce byte limits and confirm that the expected image decoder can read the result. A filename ending in .jpg is not evidence that the response contains a valid JPEG.
Concurrent requests need ordering control. If a request for an older inspection finishes after a newer one, it must not replace the newer image. Associate each retrieval with the requested inspection and confirm that it is still current before updating the view.
Show the inspection identifier and acquisition time alongside the image. Distinguish a pending image, an unavailable image and a previously captured image. If historical content remains visible, label it as historical rather than presenting it as the current result.
How to keep retrieval bounded and private
Keep source credentials in a server-side secret store or another access-controlled configuration mechanism documented by the platform. Do not place them in image URLs, browser-visible properties or client scripts.
Plain FTP does not encrypt credentials or image content. If a legacy source requires it, confine that connection to an appropriately restricted network segment and assess the exposure. Use a manufacturer-supported encrypted retrieval method where available. FTPS and SFTP are different protocols; neither becomes a browser image source merely because it encrypts the transfer.
Set connection and transfer timeouts, download-size limits, concurrency limits and a bounded retry policy. Use the platform's supported background execution mechanism rather than blocking a shared request or event thread. Close connections on both success and error paths.
An FTP control connection succeeding does not prove that the data connection will work. Firewall rules must match the server's documented transfer mode and data-port configuration. Do not solve a transfer problem by broadly exposing the FTP service.
Avoid opening a fresh transfer every time an unrelated property changes. Trigger retrieval from a defined inspection event or a controlled refresh schedule. Where several sessions request the same image, a bounded shared retrieval or short-lived cache may reduce duplicate traffic, subject to access and retention requirements.
What to check before using the image
Commission the complete path, not just a successful download. Check behavior when the source is unreachable, the file is missing, a transfer stalls, the image is incomplete and requests finish out of order. Confirm that another session cannot request images outside its authorized scope.
Use browser developer tools to distinguish an unsupported source scheme from an HTTP authorization error, a content-policy block or an image decode failure. Record retrieval timing and error categories server-side without recording credentials or image payloads.
Measure freshness from capture through retrieval to rendering. If delivery works but the displayed image arrives late, investigate factory screen update delay rather than repeatedly changing the image format.
Finally, keep this display path separate from machine safety functions. A browser image can support inspection review, but it must not replace a required protective function or serve as the sole evidence that a machine is safe to operate.
Questions
Why does a valid FTP image URL leave the dashboard blank?
Modern mainstream browsers do not natively retrieve FTP resources for an image component. A valid address and working credentials do not change that limitation. Retrieve the image through a documented server-side process, then deliver it to the browser through HTTPS or a supported data URI.
Can a dashboard display an FTP image without saving another file?
Yes, if the dashboard supports data URIs. A server-side process can retrieve the binary image, validate it and encode it into the image source. Apply download-size and timeout limits. Memory-based handling avoids deliberately saving another file, but application diagnostics or browser state may still retain copies.
Is an HTTPS endpoint better than a base64 data URI?
An authenticated HTTPS endpoint usually fits frequent updates or shared images better because base64 increases payload size and may duplicate content across sessions. A data URI can suit small, occasional images. In either case, identify the inspection explicitly and prevent an older retrieval from replacing a newer result.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.