Nano Banana 2.1

How to read these cases

The six images above come from OpenArt's Nano Banana 2.1 showcase. They are platform demonstration artwork, not output produced on this site — every card says so in the line beneath the image. Read them as evidence of what each task type looks like, not as a promise of what your own run returns.

• What they cover: a multi-reference composite, conversational editing, style transfer, batch product consistency, a coordinated catalog, and a week of social posts with one character.
• Each card names its source and its rights under the image; nothing here is presented as this site’s own generation.
• The three prompts below are untested starting points, not recorded results — run them in the workspace and judge the output against the checklist further down.

A poster for a night market, headline text NIGHT MARKET in bold condensed type, warm lantern light, crowd silhouettes, 3:2 frame.

Using the attached product photo, change only the background to a plain warm grey studio sweep. Keep the product, lighting and framing identical.

The same person from the reference, now seated at a desk by a window, soft daylight, same clothing and hair, portrait framing.

If you have a reference image and want the words for it rather than a new render, the image-to-prompt tool reverses a photo into a prompt you can then paste back into this workspace.

What Nano Banana 2.1 is

Google published Nano Banana 2.1 as a generally available image model on October 6, 2026 under the model ID gemini-nano-banana-2.1, and describes it as optimized for multimodal image generation and editing with a balance of price and performance. The model card states it is based on Gemini 3.6 Flash. It succeeds Nano Banana 2 in Google's own image line, which is why it is now the first image model listed in this site's navigation.

Google's model card lists the jobs it is built for: creating and editing images with professional levels of precision and control across multiple quick iterations, generating clear text for posters and intricate diagrams, applying long-context real-world knowledge, and rendering localized text across several languages.

Treat those as the model's design targets. The catalog remains the authority on which of them this workspace exposes today.

Open modes in this workspace

The live catalog publishes exactly two modes for this product, and the workbench offers only what it returns.

If a mode disappears or greys out, that is the catalog reporting a change upstream, not a page error. Reload and check the account workspace before assuming a fault.

• Text-to-image: you write the brief, the model draws it. Task model nano-banana-2.1.
• Image-to-image: you supply the reference you are allowed to process plus an instruction, and the model returns a new image. Task model nano-banana-2.1-i2i.
• Both modes accept the same four inputs published in the form schema: prompt (required), image_urls (optional, URL or base64), aspect_ratio and resolution.
• Google documents far more around this model — image generation from video input, multi-turn editing, virtual try-on, Google Search and Image search grounding, C2PA Content Credentials. None of those are separate controls here; only the two modes above are exposed.

How to use it, step by step

Four steps cover both modes. The order matters because the quote is requested before anything is charged.

1. Open this page's workspace and confirm Nano Banana 2.1 is the selected model. It is the default on this page.
2. Choose the mode that matches what you already have: text-to-image for a new picture, image-to-image when the subject, layout or product is fixed and you are changing something about it.
3. Set aspect ratio and resolution. Start at 1K to settle direction cheaply; move to 2K or 4K once the composition is right, because Google's own guidance is that small text suffers at 1K.
4. Read the server quote for those exact settings, submit, and wait for the polled result. A failed task reports a reason; the account workspace keeps the history.

Parameters and input limits

The catalog publishes the four fields this workspace can send. Google's model documentation publishes the wider envelope of the model itself. Both are reproduced below; where they differ, the catalog wins for anything you submit here.

Two consequences follow from that table. You cannot pin a result with a seed, so an identical prompt can still vary between runs; save the image you like rather than assuming you can regenerate it. And because structured output is not supported, do not build a pipeline that expects JSON back from this model.

Writing prompts that hold up

The model card's known-limitation list is the best prompt guide available for this model: it names partial instruction following, character drift, spatial confusion and weak small-text rendering. Write against those four.

[subject] [action], in [setting]. Composition: [framing, angle, distance]. Style: [medium, lighting, mood]. Keep [element] on the [left/right] of the frame.

Using the attached image, change only [specific element] to [new element]. Keep everything else identical — same framing, same lighting, same style.

A [format] with the headline text [exact string] set in [type style]. Keep the text legible at final size; no other text in the frame.

Three habits do most of the work. Name positions explicitly instead of relying on the model to infer them. State what you want rather than what you want to avoid. And keep one instruction per edit: the card reports partial instruction following in masked and doodle-based editing, so a long list of changes in a single turn is where results slip.

When text matters, raise the resolution before you re-prompt. Google's own limitation list names small text as often blurry at 1K.

Where it fits

These are the tasks the published modes and the model's stated design targets actually support.

• Poster and social visuals where the layout carries a short headline.
• Product and scene imagery where one object has to stay recognizable across a set.
• Reference-image editing: swap a material, a background or a single element while holding the composition.
• Infographics and diagrams, which the model card names explicitly and which benefit from search grounding.
• Localized variants of the same visual, because multi-language text rendering is a listed strength.

Where it does not fit

Every line below is published by Google or by the catalog, not inferred from a benchmark.

• Long paragraphs or dense page-length text: the model card names poor rendering for both.
• Anything needing a reproducible result: sampling controls are unsupported, so there is no seed to pin.
• Machine-readable output: structured output, function calling and code execution are all listed as not supported.
• Audio work of any kind: audio is not supported.
• Video input pipelines on this site: Google supports video input for the model, but the catalog exposes text and images only.
• Work that must be factually exact without review: the card lists hallucinations and limited factuality among the known limitations.

Common failures and what to do

The failure modes below come from Google's published limitation list plus the parts of the task flow this site controls.

Output checklist before you publish

Run this over the returned image. It is short because every item corresponds to a failure the model card or the catalog already documents.

One item is worth adding from user discussion rather than documentation: individual community posts raise doubts about prompt adherence, person similarity and whether this model really displaces the Pro tier. Those are unverified individual reports, not results. That is exactly why the checklist above asks you to verify text, likeness and claims yourself instead of trusting the first render.

1. Zoom to the final display size and read every piece of text; re-run at a higher resolution if anything is soft or misspelled.
2. Compare faces, products and logos against your reference and confirm nothing drifted.
3. Check left, right, above and below against what the brief asked for.
4. Verify any factual claim the image makes — a date, a place, a label — against a source you trust.
5. Confirm the aspect ratio and resolution match where the image will actually be used.
6. Keep the file's provenance with it. Google lists C2PA Content Credentials as supported, so treat the credential as part of the deliverable.

Choosing between Nano Banana 2.1, Nano Banana 2 and Lite

The comparison that matters on this site is the one the catalog publishes, because that is what you are actually charged for.

The honest summary: on this site, Nano Banana 2.1 and Nano Banana 2 publish identical modes, resolutions, ratios and reference prices, so there is no billing reason to prefer the older one. Lite is the only cheaper option, and it buys that with a 1K ceiling and seven ratios. Where quality differences are concerned, Google's published evaluation numbers are vendor-reported and we do not republish them as this site's findings.

Credits, quotes and where the charge is set

The reference points shown on this page come from the catalog and are an estimate, not an invoice. The server quote is computed from the settings you actually submit, and the account ledger records what a completed task cost. Nothing here is charged for browsing, quoting or reading.