Use inline Base64 for modest image updates carried through an existing application connection, and image URLs for heavier traffic over approved network paths. Add storage when you need history. Trace types, lengths and decoded bytes at each boundary to locate conversion errors.
Use inline Base64 for occasional images that must travel through an existing application connection. Use an HTTPS URL when images are larger or arrive frequently and the receiving browser has an approved route to the image service. Add storage when you need history, traceability or retrieval after the original message has passed. These choices can be combined. The important distinction is between image bytes, text that carries those bytes, and a reference that lets an application retrieve them.
Compare the delivery paths
Industrial image data delivery has two separate decisions: how the image reaches the view, and whether you retain it. Storage is not a browser delivery method by itself. A stored image still needs an endpoint or an inline representation before a browser can display it.
| Decision point | Inline Base64 | HTTPS URL | Stored image with a retrieval service |
|---|---|---|---|
| What the process message carries | Encoded image text, usually with metadata | An image URL or reference | A record key or image identifier |
| How the browser receives the image | Inside an application property, if supported | A separate request to the image service | Through an application endpoint or an inline response |
| Network requirement | Existing application connection may be sufficient | Browser needs an approved route to the service | Application needs storage access; browser access depends on delivery method |
| Message and tag load | Full encoded image passes through each participating layer | Small reference passes through the messaging path | Small reference passes through the messaging path |
| Main overhead | Base64 expands the compressed image bytes | Requests, authentication and cache handling | Storage writes, indexing, retention and retrieval |
| History | Requires separate retention | Depends on what the service retains | Supports history when records and retention are designed for it |
| Strongest fit | Modest images at a low update rate | Frequent images and multiple viewers | Inspection records, recall and audit requirements |
Do not choose solely on whether one image appears successfully. Choose for the largest expected image, the busiest update period and the number of simultaneous viewers.
Where inline Base64 wins
Inline delivery is useful when an application already sends property updates to a browser, but the browser has no approved route to a separate image host. The application can carry the image within that existing connection, provided its component and security policy permit data URLs.
Start with an encoded image file, such as PNG or JPEG. Base64 converts those file bytes into text. It does not compress the image and it does not encrypt it.
For a browser component that accepts data URLs, the value combines a media-type prefix with the encoded content. The PNG prefix is data:image/png;base64,. The JPEG prefix is data:image/jpeg;base64,. The declared type must match the actual image format.
Some components accept only ordinary URLs. Others restrict inline images through their content security policy. Confirm support in the application documentation before changing the transport.
If a bridge only supports text reliably, encode the compressed bytes before that bridge. Carry the result as an explicitly configured string. Avoid repeatedly encoding and decoding it at later hops.
Inline delivery loses its appeal when every frame travels through a broker, bridge, OPC server, tag subscription and browser session. A working string mapping does not establish that this entire path has enough capacity.
Where an image URL wins
A URL keeps the large payload out of process tags. The message can carry the image identifier, capture time and result, while an image service handles the file transfer.
The browser normally makes that request itself. A successful request from the application server does not prove that a browser on another network segment can reach the same address. Check name resolution, routing, approved firewall rules and authentication from the intended client network.
Use an approved HTTPS service. A secure application page may block an insecure image request. Authentication can also fail if the image endpoint expects credentials that the browser request does not supply. Do not place long-lived credentials in a URL or process tag.
An application-side image endpoint is another option. The browser requests the image from the application, and the application retrieves it from an approved internal service. That needs deliberate authorization, capacity planning and network approval. It is not a way around access controls.
Publish a reference only after the corresponding image is available. Otherwise, the view can receive a valid URL before the file is ready. Prefer a distinct identifier for each image, with an appropriate cache policy, rather than repeatedly replacing one file and assuming every browser will refresh it.
Where storage wins
Use storage when an image must remain available after the latest process value changes. Examples include reviewing a rejected part, comparing earlier inspections or retrieving the image associated with a batch result.
Two common arrangements are:
- Store the image bytes in a database binary field, with searchable metadata beside them.
- Store the image in a file or object store, with its identifier and metadata in a database.
Neither arrangement requires direct database access from the browser. An authorized application service can retrieve the record and return the image through an endpoint. It can also construct an inline response when the image size and update rate suit that approach.
Keep the image and its result associated by a stable identifier. Include the capture time, source identifier, media type and byte length. A content digest can help detect whether the retrieved bytes differ from the original file.
Define retention, access permissions and deletion behavior before collecting production images. Also decide what happens if a result arrives but its image cannot be stored. Do not silently treat an incomplete record as complete.
Storage adds operational work. It is justified by retrieval requirements, not merely by the fact that a database is available.
Locate byte-to-text conversion errors
Follow one known image through the complete path. Use an image identifier to connect the observations. Record data types, lengths and digests where possible instead of copying full production images into logs.
Check the publisher output
First confirm that the image encoder produces a valid PNG or JPEG file. Save or decode those exact bytes using an approved diagnostic method. An array of raw pixel values is not automatically an image file that a browser can display.
A text-oriented message viewer may show unreadable characters for a binary payload. That alone does not indicate corruption. Inspect the payload type and byte count rather than judging its appearance as text.
Check each conversion boundary
Distinguish these representations:
- Binary file bytes.
- Base64 text representing those bytes.
- A complete data URL containing Base64 text.
- An HTTPS URL or storage key.
- A programming-language display representation of a byte object.
Text beginning with b' and containing escapes such as \x89 may be a display representation of bytes, not the original binary payload. If a bridge writes that representation into a string tag, fix the bridge mapping or serialization. Do not make the view interpret diagnostic text as an image format.
Likewise, decoding arbitrary image bytes as ordinary text can replace or discard byte values. The correct repair is at the conversion boundary, using the original bytes. A later display binding cannot reliably reconstruct information already lost.
Check the receiving value
For Base64 delivery, verify that the receiving value is complete text with no added quoting or unintended line wrapping. Decode it once, then compare the decoded byte length and digest with the publisher's compressed file.
For a URL, verify that the response contains the image, not a login page, an error document or an expired reference. Check its media type and the browser's network diagnostics.
Check the view binding
A tag containing valid bytes still needs a supported input at the image component. If the component expects a URL, raw bytes are the wrong value even when every upstream hop is correct.
For inline delivery, construct the data URL exactly once. A duplicated prefix or a second Base64 encoding changes the input. If the value is intact but the component refuses it, check component support and browser security policy before altering the publisher again.
Calculate the load before selecting inline delivery
Base64 length is four times the original byte count divided into groups of three, rounded up to a whole group. In formula form, it is 4 × ceil(n / 3) characters for n input bytes, before any data URL prefix or message envelope.
For example, a compressed image of 300 KiB becomes 400 KiB of Base64 text. That follows directly from the encoding ratio. At two images per second, the encoded content alone is 800 KiB per second on each path carrying every update. Protocol overhead and copies add more. Browser fan-out can increase outbound traffic further.
Check the configured limits at every layer:
- Broker message size and publisher limits.
- Bridge payload handling and serialization.
- OPC value type and string-length limits.
- Application property and session message limits.
- Browser memory use and image decoding behavior.
Use the largest realistic compressed file, not just an average frame. Detailed scenes can produce larger files than simple scenes at the same dimensions and encoder settings.
If only the current image matters, design an explicit latest-value policy rather than allowing an unbounded queue of old frames. If every image matters, retain records with acknowledgments and controlled retries. Those are different requirements and should not share an accidental delivery policy.
Make the decision from the receiving end
Choose inline Base64 when updates are modest, the component supports it, the existing application connection is the approved path and every intermediate limit has been checked.
Choose a URL when image traffic should be separated from process messaging and the browser can reach an authorized image service. Plan authentication, availability timing and cache behavior as part of that choice.
Choose storage when you need to retrieve earlier images or associate them with production records. Then select an endpoint or inline response to deliver those stored bytes to the view.
Before implementation, write down the payload format, media type, maximum expected byte count, update rate, viewer count, network paths and retention requirement. Define what the view shows when an image is missing or a request fails, including a visible capture time so an old image is not mistaken for a new one.
This transport decision is separate from choosing between a signage display and a live dashboard. Delivering an image correctly does not, by itself, give a content player the application logic needed to retrieve and refresh live process data.
Questions
Does Base64 prevent image corruption in an OPC tag?
No. Base64 makes binary image bytes representable as text, but it does not prevent truncation, incorrect mappings or double encoding. Check each layer's data type and size limit. Decode the received text and compare the resulting byte length and digest with the original compressed image.
Why does an image URL work on the server but not in the browser?
The application server and browser can have different network access and authentication contexts. The browser may be unable to resolve or reach the image host, or its request may receive a login page instead of an image. Check the request from the intended client network and follow approved access procedures.
Should a process tag contain the whole image?
That can be appropriate for small, infrequent updates when every layer supports the payload size. For larger or frequent images, carrying an identifier through tags and retrieving the image separately usually reduces messaging load. Historical retrieval also needs deliberate storage rather than reliance on the latest tag value.
Does storing images in a database make them display automatically?
No. A database can retain image bytes or references, but the browser still needs a supported delivery method. An authorized application service can retrieve the record and return an image response or construct a data URL. The browser does not need direct database access.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.