Unable to process input image — Veo API image-to-video 400 error (Gemini API)

Published 2026-09-23

HTTP 400 INVALID_ARGUMENT Do not retry as-is

The exact error

Unable to process input image

What it means

Veo accepted your image-to-video request but could not read the image you attached as the starting frame. The response is a 400 INVALID_ARGUMENT, so the problem is in the request payload, not in model capacity or your quota.

The clearest public report is Google AI Developers Forum thread 128760. A developer built an n8n Cloud workflow that generated a PNG with gemini-3-pro-image-preview and then sent it to veo-3.1-generate-preview:predictLongRunning on the Gemini API. They put the image under instances[].image as bytesBase64Encoded plus mimeType, and every call failed with this error. The thread has no answer, so nobody has confirmed the cause. Two details in that report are worth checking in your own code:

The field shape. Google’s Veo page for the Gemini API shows the REST image as an inlineData object with mimeType and data (the base64 string). The SDK examples pass an Image object built from image bytes plus a MIME type. The forum request used bytesBase64Encoded instead. That this mismatch caused the error is our reading of the two documents, not a confirmed diagnosis.
What actually reaches the API. The same poster found that n8n Cloud keeps binary data on the filesystem, so their Code node saw a short file reference (about 13 characters) instead of base64. They had to pull the real data out with a Set node first. Any pipeline that passes binaries between steps can end up sending a reference, an empty string or a data URI instead of raw base64.

Merged variant: Image should have either uri or image bytes. This is also a 400 INVALID_ARGUMENT. It was reported in forum thread 82655 from the Python SDK’s generate_videos call against Veo 2.0. The wording says the Image object arrived with neither a URI nor bytes, which usually means it was empty. A forum member with a Google badge replied weeks later that Veo had some downtime with image inputs and that it was working for them again. So this variant has been transient at least once.

How to confirm it’s this

Send the same prompt without the image. If that succeeds, the image payload is the problem.
Log the length of the base64 string you send and the first few characters, never the whole thing. A value that is a few dozen characters long is a file reference or placeholder, not an image.
Decode the exact string you send back into a file on your machine and open it. If it does not open as an image, the API cannot read it either.
Check that the declared mimeType matches the real file type, and that there is no data:image/...;base64, prefix left on the string.

Fix

Build the image field the way Google’s Veo page shows it. Over REST that is "image": {"inlineData": {"mimeType": "image/png", "data": "<base64>"}} inside the instance. In the SDKs, pass an Image object with the raw bytes and the MIME type rather than a hand-built dictionary.
Resolve binaries before you build JSON. In n8n and similar tools, make sure the step that builds the request has the actual base64, not a pointer to stored binary data. The forum poster did this with a Set node reading the binary property.
Test with a known-good image from disk. A small PNG loaded directly into your code tells you whether the problem is your pipeline or the specific image.
Keep the other image-to-video settings valid. Google’s parameter table allows only allow_adult for personGeneration in image-to-video, so check that value too once the image is accepted.

Retry or not

No, not as an identical request. A malformed or empty image fails the same way every time, and the report in thread 128760 failed on every attempt. An agent should treat this as an input error: stop, report which image failed along with its size and declared MIME type, and rebuild the payload. The one exception is a request that worked yesterday with the same image and code. Given the downtime mentioned in thread 82655, a single delayed retry is reasonable there. If it fails again, treat it as an input error.

When it’s not this

Gemini image understanding, not Veo. The same wording, followed by a “Please retry or report” link, comes back from generateContent when a Gemini model cannot read an input image. In gemini-cli issue #5064 the trigger was a very large Figma export, and a resized copy worked. In python-genai issue #505 it appeared in a multi-turn chat after the model had generated an image. A contributor there could not reproduce it and suggested it might have been transient.
Reference images instead of a starting frame. python-genai issue #1988 reports a different input error, about a missing URI, when passing Veo 3.1 reference images through SDK 1.60.0. That is a separate problem with its own fix.
An error that names fileUri. If the message complains about a file URI rather than the image itself, see the related page below.

Error text last verified against the sources below on 2026-09-23.