Image Edit Returns Unable to Process Input Image?

Nano Banana image edits return 400 ‘Unable to process input image’ or ‘empty inlineData parameter’ because the inlineData image data in the request is empty. It has nothing to do with whether your image URL is reachable; a Cannot fetch content error with URL input means Google timed out fetching the image. Check your base64 conversion step and validate before sending.

Symptoms

When you call a Nano Banana model (gemini-3.1-flash-image-preview, gemini-3-pro-image-preview, gemini-nano-banana-2.1, etc.) for an image edit with a reference image, the API returns HTTP 400 with one of these two errors:

{
  "error": {
    "message": "Unable to process input image. Please retry or report in https://developers.generativeai.google/guide/troubleshooting",
    "code": 400
  }
}

Unable to submit request because it has an empty inlineData parameter. Add a value to the parameter and try again.

The errors usually come in a burst and then stop, which makes the API look unstable.

Cause

inlineData.data in your request is empty, so the provider never received the image. Both errors have the same cause; different nodes word it differently. One says the inlineData parameter is empty. The other says it is “unable to process input image”, which makes people think the image is corrupted or its link is unreachable.

It is not about your image URL or whether your storage bucket is public. With inlineData, the image is sent as base64 inside the request body, and the provider never fetches any link. This error means the base64 string itself is empty. The problem is in the step where your code converts the image to base64.

You can confirm this in the console logs: the failed requests have very few input tokens (just the prompt), while normal requests with an image have hundreds to thousands more.

Checklist

1. Did the download or encoding step actually succeed?

   Many programs first download the image from object storage (COS / OSS / S3) and then convert it to base64. If the download fails or times out, or the request is sent before an async step finishes, you get an empty string. Log the base64 length right before sending.

2. Is the variable undefined?

   In JavaScript, JSON.stringify silently drops fields whose value is undefined. If imageBase64 is undefined, the serialized request has only mimeType under inlineData and no data field at all, so the provider reports an empty inlineData. You can’t see this in the code; you have to log the request body that is actually sent.

3. Does data include a data URL prefix?

   inlineData.data must contain plain base64 only. If you have the full data:image/png;base64,iVBORw0... string, strip everything up to and including the comma.

4. Does mimeType match the real image format?

   Set mimeType to image/png, image/jpeg or image/webp, matching the actual format. File extensions are unreliable (some phone .jpg files are really multi-frame images). The safest approach is to re-encode everything as PNG or JPEG during conversion.

Validate Before Sending

A few lines of checks before building the request will surface the problem locally instead of as an API error:

JavaScript

const b64 = (imageBase64 || '').replace(/^data:[^;]+;base64,/, '');
if (!b64) {
  throw new Error('Reference image base64 is empty; check the download / encoding step');
}

const payload = {
  contents: [{
    parts: [
      { text: prompt },
      { inlineData: { data: b64, mimeType: imageMimeType } }
    ]
  }],
  generationConfig: {
    responseModalities: ['IMAGE'],
    imageConfig: { imageSize: '2K' }
  }
};

Python

import base64, re

def to_inline_data(image_bytes: bytes, mime_type: str) -> dict:
    if not image_bytes:
        raise ValueError("Reference image is empty; check the download / read step")
    b64 = base64.b64encode(image_bytes).decode()
    return {"inlineData": {"data": b64, "mimeType": mime_type}}

def strip_data_url(s: str) -> str:
    b64 = re.sub(r"^data:[^;]+;base64,", "", s or "")
    if not b64:
        raise ValueError("Reference image base64 is empty")
    return b64

This 400 is caused by the request itself, so retrying the same request will not succeed. Once your code is fixed, no platform-side configuration is needed.

Want to Pass an Image URL Instead?

The native Gemini endpoint also accepts an image link directly. Use fileData, not inlineData:

{
  "fileData": {
    "fileUri": "https://your-bucket.example.com/ref.png",
    "mimeType": "image/png"
  }
}

With a URL, Google’s servers have to download the image. If your storage is served only through a mainland China CDN (for example, Tencent Cloud COS with default settings), Google often can’t reach it. The usual symptom is that the result ignores the reference image, not an error. Where possible, base64 is the more reliable option. See the Nano Banana Developer Guide for details.

URL Input Returns Cannot fetch content from the provided URL

When you pass images with fileData.fileUri, you may also hit a different 400, and this one does return an error:

{
  "error": {
    "message": "Cannot fetch content from the provided URL. Please ensure the URL is valid and accessible. Status: URL_REJECTED-REJECTED_FC_TIMEOUT",
    "code": 400
  }
}

This means Google’s servers timed out while downloading your image. It is unrelated to an empty inlineData. Google allows roughly 60 seconds to fetch a URL, and if your storage responds slowly to Google’s servers, the request hits that limit. The telltale sign is that every failure comes back at about 60 seconds.

An image that opens instantly in your browser is not necessarily fast for Google to fetch. We tested a roughly 500KB PNG hosted on overseas object storage (AWS S3, US West): the same link downloaded locally in under a second, but when Google fetched it, 5 of 8 requests failed with the error above at about 60 seconds, and the successful ones still took 60–77 seconds. Sending the same image as inline base64 succeeded every time, in about 18 seconds. Switching channels made no difference, so the issue lies between Google and that storage host, not in APIYI’s channels.

How to fix it:

1. Send base64 with inlineData (recommended): download the image yourself and convert it to base64 so Google no longer has to fetch anything. This error goes away entirely. Keep the non-empty base64 check described above.
2. If you must use a URL, cut down how long Google takes to fetch it: set the object’s Content-Type to its real format on upload (such as image/png, not the S3 default binary/octet-stream), and prefer a global CDN address such as CloudFront. This helps but does not guarantee the timeout won’t happen.

A second request for the same URL is often faster because Google caches images it has already fetched. So “it worked when I retried” only means that image was cached. A new image will time out again, so don’t treat it as fixed.

FAQ

My image is publicly readable. Why do I still get this error?

With inlineData, the provider never fetches any link, so public access doesn’t matter. Check the step where your code converts the image to base64 and make sure the data field you send is not empty.

Are these failed requests billed?

No. The request is rejected at the provider’s entry point, no image is generated, and no charge is made. URL fetch timeout 400s are not billed either. The console call logs are authoritative.

Related Docs

Nano Banana Developer Guide

Input image requirements, URL input and timeouts

Gemini Image Error Handling

How to handle each error and finishReason

Image MIME Type Mismatch?

Format mismatch caused by processing parameters in image URLs

Image Compression and Resolution

Compressing reference images does not hurt output quality