Design Journal · August 25, 2026 · Reliability
An Image Prefix Is Not an Image
Why truncated data URLs remain ordinary tool text instead of becoming fatal image uploads.
A harmless excerpt ended the run
A browser script returned JSON with a shortened image source. The formatter matched its base64-looking prefix, decoding failed inside after_tools, and an otherwise successful agent run terminated.
Length was not proof
Catching one padding error or imposing a minimum length would still accept some truncated payloads. Text can decode successfully without being an image, and an image header alone does not prove the file reached its end.
The new boundary
PNG, JPEG, GIF, and WebP candidates now require strict base64 decoding, the declared format signature, and complete terminal structure. Invalid candidates remain ordinary tool text. Genuine images still upload to oo-api, and genuine network or HTTP failures still fail loudly.
Evidence and limit
The regression includes the exact production prefix from issue #1269 and decodable non-image text, while complete-image unit and plugin E2E paths still pass. A future format must add its own completeness rule.
See image_result_formatter for usage.
ConnectOnion