Fix database image display in a signage view

What each symptom points to

Use the symptom to choose your first check:

• A local image works, but the database version is blank: inspect the query result and source transformation before changing the display layout.
• The query returns a row, but its image cell is empty: check the selected record, null handling and column selection.
• The source contains an object description or a list of numbers: the transformation is using a representation of the binary value rather than its bytes.
• The payload decodes to another base64 string: the image has probably been encoded twice.
• Small images work, but larger uploads fail: investigate request limits, storage limits, image dimensions and memory use separately from source formatting.
• The URL opens a login page or an error page: the browser is not receiving an image, even if the request returns a successful status.

If the retrieved file itself cannot be opened, follow the separate signage image file troubleshooting checks. The steps below focus on the database-to-browser boundary.

Inspect the stored value before transforming it

Start with one small, known-good image in a development view. Keep the original file available for comparison.

Check these points in order:

1. Confirm the record. Read back the identifier returned by the insert. Do not rely on an unrestricted query returning the expected row first.
2. Inspect the returned type. A database driver may return a byte array, a binary stream, a wrapper object or text. Use its documented method for obtaining the contents.
3. Compare lengths. If the design stores raw binary, the retrieved byte count should match the uploaded file's byte count. A mismatch suggests conversion, truncation or a different stored value.
4. Compare the contents. Save an authorized local copy through your application's supported tools. Compare its checksum with the original when both are available.

A binary column can contain base64 text. Its column type alone does not tell you what the upload handler inserted.

Inspect a short prefix rather than writing the complete image into application logs. Raw PNG files begin with the hexadecimal signature 89 50 4E 47 0D 0A 1A 0A. JPEG files normally begin with FF D8 FF. These signatures help identify the format, but they do not prove that the complete file is valid.

Match the source format to the image

A browser-based image component commonly accepts an image URL or a data URI. Check the component's documentation for its supported source formats.

A base64 data URI has three parts: the media type, the ;base64, separator, and the encoded payload. For example, a PNG source begins with data:image/png;base64,. A JPEG source begins with data:image/jpeg;base64,.

Check the exact value assigned to the component:

• Use image/png for PNG bytes and image/jpeg for JPEG bytes.
• Remove accidental spaces inside the media type, such as image/ jpeg.
• Include the comma between the header and payload.
• Do not include a byte-array label, surrounding quotation marks or an object's string representation as part of the payload.
• Use an encoder that produces a single base64 string without inserted line breaks.

Do not treat a changed filename extension as a format conversion. Identify and validate the actual image, then associate the correct media type with it. A mismatched media type can cause rejection or inconsistent behavior between renderers.

Encode at one boundary

Choose a storage contract and apply it consistently. The simplest contract for a binary column is usually:

1. Store the original image bytes.
2. Retrieve those bytes without converting them to ordinary text.
3. Base64-encode them once when constructing a data URI.
4. Add the media type and data URI prefix once.

Use the encoder supplied by your application runtime. Do not encode the result of converting a binary object to a display string.

For an existing database that intentionally stores base64 text, do not base64-encode that text again. Validate it, decode it once to check the resulting image, and then use the validated payload according to the storage contract. If records contain mixed formats, identify and migrate them explicitly rather than guessing during every display refresh.

A useful check is to remove the data URI prefix and decode the payload once. The result should be image bytes that match the stored original. If it is readable text beginning with another base64 image prefix, an extra encoding step exists somewhere in the route.

Comparing only the first few characters is not enough. A matching prefix can still hide a truncated or damaged file.

Choose embedding or URL delivery by workload

Embedding is convenient for small icons and thumbnails. It becomes less attractive when the same view repeatedly transfers large images.

Base64 represents each group of three input bytes with four characters. Its encoded length is 4 × ceil(byte_count / 3), before the data URI prefix and any surrounding message structure. A 3 MiB binary image therefore produces 4 MiB of base64 text. That is transfer size, not a prediction of total memory use.

A URL lets the browser request the image separately and use normal HTTP caching when the response policy allows it. It does not automatically make delivery efficient: returning an entire large file through an inefficient endpoint can still consume substantial server resources.

Database storage is not inherently wrong for images. The decision depends on image volume, access patterns, backup requirements and the application's supported serving route. Moving to URL delivery does not necessarily require moving existing files out of the database.

Fix upload and memory limits separately

There is no universal file size at which an image upload crashes a server. A failed upload needs evidence from application logs, request limits, database errors and memory measurements.

Several copies can exist during one operation: the received file, a decoded image, query parameters, encoded text and cached results. Concurrent uploads and multiple open views can increase that load.

Set controls at the upload boundary:

• Limit both compressed file size and decoded pixel dimensions. A relatively small compressed file can still require a large decoded image buffer.
• Validate the image format on the server, not only through a filename or browser file selector.
• Generate a thumbnail for the view instead of repeatedly loading the full-resolution original.
• Review query caching before retaining large binary results. Use bounded caching where the application supports it.
• Keep list queries focused on identifiers and metadata. Fetch image contents only when needed.
• Review database column capacity and driver behavior if retrieved bytes are shorter than the original.

If files move to separate storage, save an application-controlled object identifier or relative reference in the database. Do not let an arbitrary client-supplied path select files from the server. Coordinate file retention and backups with the related database records.

Check the complete delivery route

Verify the fix with the same component and access conditions used by the deployed view:

1. Load a small PNG and a small JPEG through the upload route.
2. Read each record back and compare the retrieved bytes with its original.
3. Inspect the final source property, not just an intermediate query result.
4. For a data URI, decode its payload once and confirm that the result opens as the expected image.
5. For a URL, inspect the browser's network response. Confirm the status, image body and matching Content-Type header. Check that authentication has not redirected the request to a page.
6. Update one image and confirm that the view receives the replacement. Use supported cache controls or versioned resource addresses if stale content remains.
7. Repeat with representative image sizes and expected concurrent sessions in a staging environment.

If the browser reports a content-security restriction, use a delivery route permitted by the application's documented policy. Do not remove security controls merely to make an embedded image render.

For supported image files, the content checker can help inspect dimensions and preview exported content. It does not inspect database records, authenticate to image endpoints or validate a data URI transformation.

Keep browser delivery separate from offline playback

A database-backed browser view and an offline image playlist are different systems. The web page signage player overview explains that boundary. A working database image component is not evidence that an offline player can execute the same query or render the same application.

For a production information screen, andon board planning helps define the display's role before choosing the delivery method. If the requirement is a periodic snapshot rather than a live browser view, prepare an ordinary image export instead. The database can remain upstream without becoming part of the display's playback route.

Questions