Si Nano Banana Pro muestra 'Unsupported file URI type' o 'Invalid or unsupported file uri', no empieces corrigiendo el prompt. En la mayoría de los casos el problema no es que el modelo haya dejado de entender imágenes, sino que la imagen nunca llegó a Gemini por la ruta de archivo correcta.
Lo primero es separar dos cosas: qué enviaste y qué surface de Gemini lo rechazó. Native Gemini file_data, OpenAI compatible image_url, la ruta gs:// de Vertex, un HTTPS público y una ruta local no comparten el mismo contrato de URI. Que una cadena parezca un URI no significa que la surface actual la trate como file resource válido.
Tabla de ruta en 30 segundos
En este error lo más importante es dividir primero por surface y tipo de input. A fecha de 2026-04-09, la documentación oficial de Gemini sigue separando claramente tres contratos: native Gemini usa Files API o files.register, la vía compatible usa image_url, y Vertex mantiene su propia lógica de object route.
| Qué enviaste | Problema más probable | Primer movimiento más seguro | Cómo verificar en la misma ruta | Cuándo subir el nivel del diagnóstico |
|---|---|---|---|---|
| URL pública HTTPS | Trataste un objeto público como si ya fuera un file resource nativo de Gemini | En Gemini, primero sube el archivo o registra el object subyacente si el origen real es GCS | La misma petición de Gemini ahora acepta el archivo | Incluso el file resource devuelto sigue fallando |
data:image/...;base64,... | Elegiste mal la surface o el base64 se corrompió en el camino | Mantén image_url en la ruta compatible y vuelve a generar un payload limpio | La misma petición compatible ahora acepta la imagen | Incluso un payload limpio sigue fallando |
gs://bucket/object | Mezclaste native Gemini con Vertex | En Gemini usa files.register; en Vertex mantén gs:// | La misma surface ahora acepta el objeto | Incluso la ruta cloud alineada con docs sigue fallando |
Ruta local como /tmp/a.png o file:///... | Tu app trató una ruta del dispositivo como si fuera un file URI reutilizable | Primero sube el archivo y usa el resource devuelto | El mismo flow ahora funciona con un resource válido | Tras el upload sigue fallando o el wrapper reescribe la solicitud |
Hay un matiz importante que conviene separar desde el principio: que el formato de imagen sea compatible no significa que la ruta de archivo sea correcta. La documentación actual de Gemini sigue listando PNG, JPEG, WEBP, HEIC y HEIF, pero el error de esta página suele aparecer antes de que el modelo reciba un resource utilizable.
Si estás usando native Gemini file_data
Native Gemini no espera cualquier cadena que parezca un URI. Espera un file resource que Gemini reconozca como propio. Si metes un public URL o una ruta local directamente en file_uri, estás entregando algo que native Gemini no considera un recurso reutilizable.
Las Files API docs actuales describen el flujo de forma muy clara: primero upload, luego reutilizas el file.uri devuelto. Si tu archivo original vive en Google Cloud Storage, el actual Files API reference ya documenta files.register, o sea una vía oficial para registrar un GCS object como File resource sin fingir que el public URL ya lo era.
Por eso tantas respuestas viejas del foro hoy se quedan cortas. Todavía verás consejos del tipo “AI Studio / Gemini no usa GCS; gs:// es solo para Vertex”. Como advertencia para no mezclar surfaces, sigue sirviendo. Como verdad completa de 2026, ya no. La formulación más precisa ahora es esta: un public URL arbitrario no es un native Gemini file resource, pero sí existe una ruta oficial files.register para GCS object.
También conviene recordar la vida útil de esos resources. Las current Files API docs indican que los archivos subidos se conservan 48 horas. Si la misma petición funcionaba ayer y hoy falla de forma parecida, no culpes primero al prompt o al modelo. Comprueba si estás reutilizando un resource vencido.
Si estás usando OpenAI compatible image_url
Esta rama es la más engañosa porque la misma frase de error puede aparecer incluso cuando la surface correcta ya está elegida. Las Gemini OpenAI compatibility docs siguen mostrando ejemplos multimodales con image_url, incluyendo valores base64 data:image/...;base64,.... Es decir, data: no está prohibido en todas partes. Solo pertenece a la ruta compatible.
Por eso la pregunta útil aquí no es “¿Gemini soporta data: URL?”. La respuesta actual es sí, pero solo dentro del route compatible. La mejor pregunta es “¿mi payload llegó exactamente con la forma que pide esa ruta?”. Un base64 escapado como HTML, un wrapper que reescribe content, o un cliente compatible que transforma el campo pueden producir el mismo unsupported-file-URI aunque la route en sí sea válida.
El orden de reparación aquí es directo: confirma que realmente estás en la surface compatible, conserva la forma image_url, regenera el base64 desde el archivo original y reenvía sin más transformaciones. No intentes arreglar esta rama copiando lógica de native Gemini file_data, porque lo normal es que eso mezcle dos contratos en vez de resolver uno.
Este bloque existe precisamente porque el propio Google AI Developers Forum ya muestra ese falso atajo. Hay casos actuales con Unsupported file uri: data:image/png;base64,..., mientras que las docs oficiales del mismo día siguen aceptando data: en image_url. La conclusión útil no es “la doc está mal”, sino “la misma frase puede venir de una route equivocada o de un payload roto”.
Si tu input es un GCS object, un public URL o una ruta de Vertex
Un public URL, un Gemini file registrado y un gs:// de Vertex no son intercambiables. Ese es el punto que más suelen simplificar las respuestas cortas.
Si estás en native Gemini y enviaste un HTTPS público, seguramente confundiste “el objeto es accesible por web” con “Gemini ya tiene un file resource”. No son lo mismo. Un URL puede abrirse en el navegador y seguir siendo inválido para native Gemini file_data. La corrección más segura sigue siendo Files API upload o, si tu source of truth está en GCS, files.register. Lo que se registra es el object, no su envoltorio web público.
En Vertex AI la lógica cambia. Allí gs://bucket/object sí puede ser la forma natural. El error aparece cuando esa experiencia se traslada intacta de vuelta a native Gemini y se asume que todos los image routes “de Google” comparten el mismo contrato. No lo comparten.
Por eso, en esta rama la pregunta correcta no es “¿GCS funciona o no?”. La pregunta es “¿qué surface es dueña de esta petición ahora mismo?”. Si es native Gemini, muévete hacia upload o files.register. Si es Vertex, mantén la route de Vertex. Si solo pegaste un public URL porque parecía un URI, conviértelo antes en un file resource que la surface actual sí reconozca.
Si tu app envió una ruta local
Una ruta local parece convincente porque el archivo de verdad existe ahí. Pero /tmp/example.png, file:///storage/... y valores parecidos son referencias de tu dispositivo o proceso, no file resources que Gemini pueda volver a recuperar más tarde.
La regla cross-platform más segura sigue siendo upload first. Primero conviertes el archivo en un resource gestionado por Gemini, después reutilizas el URI devuelto. Antes de eso, la ruta local solo demuestra que tu app ve el archivo, no que Gemini lo pueda usar como resource externo.
En SDK móviles y wrappers sí existen casos más finos, como content:// u otras particularidades del cliente. Pero esas excepciones no deben dominar el relato principal. Mientras no hayas corregido la route primaria, bajar demasiado pronto a matices de SDK suele hacerte perder tiempo sin desbloquear la solicitud.
Cómo verificar la corrección y qué sospechar después
Que el error desaparezca una vez no significa que el problema haya quedado bien cerrado. El orden más seguro es este:
- Cambia solo un paso mínimo de file route y vuelve a probar en la misma path.
- Confirma que la misma solicitud no solo acepta el archivo, sino que además cumple el job real que intentabas ejecutar.
- Si ya habías hecho upload o register antes, revisa si el resource se venció.
- Si la route ya está claramente bien y el error sigue, pasa a base64 integrity, wrappers que reescriben la request o cliente viejo.
La frontera más útil aquí es qué no debes culpar demasiado pronto. Este síntoma rara vez significa que Nano Banana Pro haya dejado de entender imágenes. Mucho más a menudo significa que la imagen ni siquiera llegó al modelo por una route soportada. Solo después de alinear la route tiene sentido pasar a payload, caducidad del resource o comportamiento de plataforma.
Si al llegar ahí descubres que el fallo real ya pertenece a otra clase de errores de imagen, la mejor continuación es la guía de errores comunes de Gemini image.
FAQ
¿Puedo poner un public HTTPS URL directamente dentro de native Gemini file_data?
En general no. Un object URL público no es lo mismo que un Gemini File resource. En native Gemini, la ruta más segura es upload o files.register si el origen real es un GCS object.
¿data:image/...;base64,... está soportado?
Sí, pero solo dentro del route OpenAI compatible image_url. A fecha de 2026-04-09, las current docs de Gemini lo siguen mostrando. Si aun así falla, primero revisa la integridad del payload.
¿Puedo enviar una ruta local como /tmp/a.png o file:///...?
No como si ya fuera un Gemini file URI reutilizable. La forma más segura es subir primero el archivo y luego usar el resource devuelto.
¿files.register reemplaza al upload?
No en todos los casos. Es la route oficial para GCS object, pero los archivos locales siguen necesitando upload primero.
¿Qué hago si la route ya está corregida y el error sigue?
En ese punto ya no estás ante un pure route bug. Revisa base64 corrupto, resources vencidos y wrappers o SDK que reescriben tu solicitud.
Qué regla conviene recordar
La corrección limpia más rápida no es “cambiar el prompt” ni “pasarlo todo a PDF”. Es identificar la surface actual, mover el archivo a la route que esa surface sí soporta, verificar en la misma path y solo después sospechar de payload o comportamiento de plataforma si el error continúa.