Fix a mobile image upload that succeeds but returns no usable picture

The server responds successfully, but the story displays a broken image. The application may have sent metadata instead of the file or accepted an unexpected response shape.

Why this happens

Local file URIs, multipart payloads and remote delivery URLs are different things. A local device path cannot serve as the public image URL for other readers.

Step-by-step solution

1. Inspect the picker result and confirm the selected asset exists. Build the upload payload according to the API’s expected file field and metadata.

2. When using FormData, let the networking implementation set the multipart boundary rather than hardcoding an incomplete Content-Type header.

3. Validate the server’s returned asset identifier and secure delivery URL, then save that media reference with the story. Keep signing secrets on the backend.

Worked example

A value beginning file:// belongs to the device. After a Cloudinary upload, the story should reference the validated HTTPS delivery asset, not that local URI.

Verify the fix

Open the resulting image from another device or a logged-out browser. Test cancellation, an oversized file and a failed upload without losing the story draft.

Prevent a repeat

Separate selection, upload and story-save states in the interface. Do not mark an attachment ready until the upload response has been validated.

Reference

Official documentation or standards guidance

An original Gistmax troubleshooting guide. Scenarios and sample values are illustrative; configuration depends on your software version and environment. Cover diagram: Gistmax Tutorials.