Nano Banana API

What the endpoint is, and why the name is the real one

Nano Banana started as a nickname and became the product name. Google's own documentation says it plainly: "Nano Banana is the name for Gemini's native image generation capabilities."

So there is no correction to make here. The thing people call Nano Banana is what the documentation calls it too, and the model IDs underneath it are ordinary Gemini names.

As of 2026-09-16 the documented line is four models: Nano Banana 2 Lite (gemini-3.1-flash-lite-image), Nano Banana 2 (gemini-3.1-flash-image), Nano Banana Pro (gemini-3-pro-image), and the legacy Nano Banana (gemini-2.5-flash-image). Those IDs move faster than anything else on this page; read the current list rather than trusting this paragraph in six months.

Generating an image

Generation is a normal Gemini request that returns image data instead of text. The call shape is the one Google Gemini API describes, with an image model selected and a prompt describing what you want.

What comes back is image bytes, which is the first practical difference from a text call: you are now responsible for storing something, and image generation covers why you cannot treat regeneration as a substitute for storage.

Editing across turns, which is the reason to choose it

The distinctive capability is not generating one image. It is changing one.

Google recommends the conversational route over re-prompting: "Multi-turn conversation is the recommended way to iterate on images." You reference a previous generation with previous_interaction_id, and the next instruction applies to that image rather than starting over.

The difference matters because the alternative is worse than it sounds. Editing by rewriting the prompt gives you a different image that happens to share a description. "Make the sky darker" as a fresh prompt produces a new scene with a darker sky, not your scene with a darker sky. Referencing the previous interaction keeps the subject.

For a product where someone refines an image over several steps, that is the whole feature. It also means your application has to carry the interaction ID as conversation state, which is one more thing to store alongside the bytes.

Reference images and their limits

Beyond editing a previous result, you can supply images as references, and the budget is bounded and structured rather than a single count.

The documentation gives up to 14 reference images in total, made up of up to 10 object images, up to 4 for character consistency, and up to 3 for style. Those are documented for the models current on 2026-09-16.

The split is worth reading as a design hint. Character consistency and style are treated as different jobs from "here is an object to include", which tells you the useful way to supply references: say what each one is for rather than uploading a pile and hoping.

What ships with every image

Every image carries a watermark. "All generated images include a SynthID watermark."

This is a property of the output rather than an option, and it has product consequences worth settling before you ship. Images from this endpoint are detectable as generated by tools that read SynthID. If your product implies otherwise, or if a customer expects to use the output somewhere that disallows generated imagery, that is a conversation to have early rather than after launch.

It also counts in your favour in the other direction: provenance marking is increasingly something a platform or a client asks about, and having it by default is one less thing to build.

Whether other providers mark their output, and how, is a per-provider question. Check it rather than assuming either way.

Further reading

• Google, Image generation: the product name, the model IDs, multi-turn editing, reference limits, and SynthID.
• Image generation: the decisions that apply whichever provider you use.
• Google Gemini API: the request shape and the safety settings around it.