A working reference for editing images with Nano Banana 2 (NB2 / Gemini 3.1 Flash Image), with emphasis on tagged reference images. Compiled from Google Cloud’s prompting guide, fal.ai, corroborating community testing, and the author’s own empirical findings from extensive trial and error. Last updated May 30, 2026.

What NB2 is, and why it changes how you prompt

NB2 is built on Gemini 3.1 Flash Image. It is not a diffusion model — it uses multimodal reasoning, encoding each image as a sequence of visual tokens predicted autoregressively through the same pipeline that handles text. Practical consequences:

  • It wants natural language, not keyword soup. It parses creative intent holistically rather than matching CLIP-style embeddings.
  • It can reason about spatial relationships and plan a composition before rendering.
  • It reads labels and tags semantically — which is the entire reason reference-image tagging works.

It is the speed/iteration model. Nano Banana Pro (Gemini 3 Pro Image) is the deeper-reasoning model for complex multi-step edits, dense typography, and physically precise fluids. Use NB2 for fast refinement cycles; reach for Pro when an edit’s reasoning load is genuinely high.

The organizing principle: talk to it like a person

This is the single most important thing in this guide, and it overturns most of the spec-sheet advice that earlier versions inherited from online research and community guides. NB2 responds better to casual, intent-forward language than to rigid, robotic, itemized instructions. Tell it what you want the way you’d tell a competent collaborator — give it character, context, and vibe, and let it work. Spec lists, ceremonial scaffolding, and over-formal constraint language make results worse, not better.

Verified over many hours of tuning (Ryan’s prompts, not community claims):

  • World-building beats parts-lists. “This jacket is old. She stole it from a corpse.” and “third-hand, maybe fourth” render better wear and grime than any itemized list of tears, stains, and fading. Give the model the story of the object and it fills in the physical detail correctly.
  • Naming what’s wrong, plainly, is a real technique. Opening an edit with “This looks like a model cosplaying a survivor. It doesn’t look realistic.” and then redirecting works. The model uses the diagnosis to steer.
  • Casual preserve clauses work. “That’s it. Those are the only changes I want.” and a trailing “Don’t touch the background” hold as hard constraints. You do not need a front-loaded categorical preserve block or a “change only X” clause structure.
  • Profanity reads as a seriousness signal. Empirically, swearing in a constraint (“don’t fucking touch the background”) increases adherence. The model appears to treat it as emphasis. (Yes, this is funny. It also works.)

Everything below is downstream of this. Where a technique in this guide reads as rigid or ceremonial, default to the casual version.

The one carve-out: surgical operations need precise, dictated instructions. Casual-and-vibes is the default, not a universal law. When the model has to hit an exact geometric target — placement, scale, exact-diameter or dimension matching, 1:1 overlay work — there is no “vibe” version of “match this diameter at 1:1,” and casual language fails. These operations require precise dictated instructions and explicit checks. Geometric/placement targeting is the known case (see the ring/annulus finding under annotated reference images); other surgical operations almost certainly qualify too — when you’re dictating exact dimensions or positions rather than describing intent, switch registers. Precise and casual aren’t opposites: you can dictate a geometric constraint in plain language. The line is intent (casual) vs. exact target (dictated), not tone.

Tech specs that matter for editing

  • Reference images: up to 14 per prompt. MIME types: png, jpeg, webp, heic, heif.
  • Resolutions: 0.5K (512px), 1K, 2K, 4K. (2K/4K cost more.)
  • Aspect ratios: 1:1, 3:2, 2:3, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9 — plus extreme ratios 1:4, 4:1, 1:8, 8:1.
  • Knowledge cutoff: January 2025. Optional live web grounding via enable_web_search / enable_google_search.
  • All output carries a SynthID watermark and C2PA content credentials.

Tagging and labeling reference images

Two methods are documented. They are not mutually exclusive — combine them.

Positional reference (@img1)

The @imgN tag is addressing — it tells the model which uploaded image you mean. So:

  • One image, no tag. When there’s a single reference image, tagging it is redundant. Just talk about “the image” or describe the change directly. “@img1” on a lone image is noise.
  • Multiple images, tag them. When there’s more than one image, you need tags so the model knows which is the base and which is the source. This is where addressing earns its keep:

I want to make one change to @img2. Her bandanna should be the fabric from @img1. Same faded pattern, same dirt and grime. Same stains. That’s the only change I want.

The model reads features directly off the tagged image, so you don’t need to re-describe them in text.

Role-labeled reference

When passing multiple images, label what each image is for, not just which slot it occupies. Assign each reference a distinct purpose — structure, texture, subject, style, product — so the model tracks which element comes from where.

Google’s multi-reference formula:

[Reference images] + [Relationship instruction] + [New scenario]

>

Example: “Using the attached napkin sketch as the structure and the attached fabric sample as the texture, transform this into a high-fidelity 3D armchair render. Place it in a sun-drenched, minimalist living room.”

The key move: scope your tags

Don’t just point at a reference — say what to take from it and what to ignore. If @img2 is there only for a shape, tell the model that explicitly, or it may also pull in that image’s lighting, texture, or camera angle.

Reference @img2 and @img3 only for the shape of the central lens. Do not pull texture, color, or camera angle from them.

Editing with annotated reference images

No first- or third-party documentation exists for these techniques. Results vary by technique — see individual sections for confidence levels.

The idea: annotate a separate reference image with colored shapes, boxes, arrows, or text labels, then pass it alongside the base image (@img1 = annotated reference, @img2 = base image to edit) and reference the annotation in the prompt to target specific areas or specify placement.

Critical structure rule: annotated reference prompts always require two images minimum. @img1 carries the annotation, @img2 is the base image. Never use a single image for both roles — this produces contradictory instructions.

Filled colored dot / circle as a placement marker

Confirmed reliable. Tested across five separate trials with four-out-of-four and five-out-of-five hit rates on location targeting. A filled colored circle placed on a separate reference image reliably directs NB2 to place an element at that exact location and scale — without any textual location clues in the prompt. The model reads the dot’s position and size from the reference image and executes accordingly.

Use a color that doesn’t appear elsewhere in the image to avoid ambiguity. The dot does not appear in the output.

Prompt pattern — say it casually, not as a legal disclaimer. The model needs two facts: the circle marks a spot, and it shouldn’t draw the circle itself. That’s it:

Using @img2 as the base, put [element] where the red circle is in @img1 — match its size to the circle. The circle’s just a marker, don’t draw it.

Annotated reference image.
Annotated reference image.
Generated result.
Generated result.

Colored boxes as region targeting

Unconfirmed — does not appear to work reliably. Attempts to use red/green bounding boxes on a reference image to tell the model “change what’s inside this box, preserve what’s outside this box” have not worked. The model ignored box boundaries and applied edits globally. Box-based region targeting is not recommended.

The model does not render annotation boxes in output — declaring them as non-content is unnecessary.

Text labels and arrows

Partially confirmed. NB2 reads text and arrows drawn onto an image and understands them as directional instructions — consistent with its general semantic image understanding. Declaring them as instructions rather than content in the prompt is the correct framing. Arrow-based location targeting has worked in testing but with less consistency than the filled dot technique.

Ring / annulus annotation — a surgical case that needs precise instructions

This is the carve-out to the casual default. A ring-shaped annotation (a band marking an annulus, not a filled dot) is less reliable on scale — NB2 tends to rescale it larger and push it outward. Fix that landed in testing: frame the annotated reference as a literal 1:1 overlay of the base image (“@img1 is @img2 with one annotation added; the red ring marks at 1:1 the exact diameter and band thickness”) and add an explicit size check (“if the element you are about to draw is bigger than the red ring, it is wrong — shrink it”). Leaning harder on the annotation beat adding workaround machinery. Session-tested, not documented — confidence: worked here, single case.

This is exactly where dictated precision earns its keep over casual phrasing: you’re matching an exact diameter, not describing intent.

Current assessment

The filled colored dot/circle on a separate reference image is the most reliable annotation technique confirmed to date — use it for placement targeting. Box-based region targeting does not work. Arrow-based targeting works sometimes. Ring/annulus annotations need the 1:1-overlay + size-check treatment above. No official documentation exists for any of these techniques.

Perspective warping onto curved surfaces

A verified, high-value technique. A flat reference element — a port, panel, decal, strip of tape — placed onto a curved surface reads as a flat sticker unless the prompt explicitly describes the geometric distortion required. “Warp it to the surface” alone does not work. Describe the specific distortion geometry instead.

Warping onto a sphere

The [element] sits on a sphere. Render it in correct perspective for that spherical surface: conforming to the hull’s curvature, foreshortened by the curve at that location. Its near edge (toward the viewer) reads larger, its far edge compressed, consistent with the sphere turning away. Seat it into the hull as built-in hardware, not a sticker on the surface.

For a circular element, name the resulting shape explicitly — “reads as an ellipse, not a flat head-on circle.” For a strip or tape, describe how it follows and bends with the curvature along its length.

General principle

Name the specific distortion: ellipse, near edge larger, far edge compressed, follows the curve along its length. The more precisely you describe the physical result of correct perspective, the better the model executes it. “Warp for the curvature” is not enough — it needs to know what warped looks like.

Verified working on a spherical hull for both a circular iris mechanism and strips of adhesive tape.

Editing structure

Editing is a different mindset from generating: you already have a base image, so the prompt’s job is to state what changes and what stays — said conversationally, not as a structured template. State the change in plain imperative (“Make her bandanna flat white thin cotton”), give it context where context helps, and close with a casual stop-clause.

Lean preserve, casual phrasing

NB2 treats a short, casual preserve instruction as a hard constraint. You do not need to itemize, and you do not need a front-loaded categorical block or a formal “change only X” clause. Trailing conversational preserves work:

  • “That’s it. Those are the only changes I want.”
  • “Don’t change the pose or framing. Definitely don’t touch the background.”
  • “Don’t make her look older.”

These hold. Stack them at the end of the prompt as plain sentences. A stop-clause like “That’s it, that’s the only change” is doing real work — it reads as a hard boundary.

Photorealism in edits — fidelity spec vs. conversion

Earlier versions of this guide claimed photorealism directives are a flat no-op in edits. That’s wrong, and the distinction matters:

  • Photorealism as conversion (no-op). Asking NB2 to take the existing image and restyle the whole thing — “make this CGI slop photorealistic” as the change itself — usually no-ops. It’s an abstract whole-image restyle with nothing concrete to grab.
  • Photorealism as a fidelity spec on your changes (works, use it). When you’re making concrete edits and you tell NB2 to render those changes at UHD 8K photorealistic, no CGI — it works, and it’s load-bearing. It stops the model from rendering the new material as digital-art slop. Drop it and your new elements can come back looking like CGI.

So in edit prompts, close with a fidelity spec like “All changes should be done at UHD 8K photorealistic fidelity. No CGI or digital art.” That’s not the no-op case — that’s the working case. Include it.

Material / texture transfer

Transferring a material from one image onto an object in another — a fabric, a surface texture, a finish — is a documented NB2 capability (Google’s own guide: “using the attached fabric sample as the texture, transform this into a render”). Say it plainly and conversationally:

I want to make one change to @img2. Her bandanna should be the fabric from @img1. Same faded pattern, same dirt and grime. Same stains. That’s the only change I want.

Name what to pull from the source. “Same faded pattern, same dirt and grime, same stains” beats a blanket “the fabric from @img1.” Naming the attributes gives a tighter grip.

For transfer onto a draped or contoured object, say the material follows the form. Add something like “following the folds so it reads as real draped cloth.” Without it, NB2 can paste the source on flat and the object goes lifeless.

This is generative compositing, not material simulation — always do a realism check on deep folds and edges.

When an edit no-ops (input returned unchanged)

NB2 sometimes returns the input image essentially untouched. This is a known failure with more than one cause; work the ladder rather than guessing.

  1. Reroll once or twice. No-ops are sometimes transient — the classifier and the generation are not fully deterministic.
  2. Give it a concrete, unmistakable delta. Soft, low-magnitude instructions (“re-render at higher quality,” “fade it a little more”) invite a no-op — NB2 looks at an image that already roughly matches the words and decides there’s nothing to do. Replace with a stated, clearly-visible change (“strongly desaturate the deep blue areas,” “rebuild the pattern from scratch”).
  3. If it still no-ops, it may be an edit NB2 won’t do — fall back to Photoshop. A saturation pull, a material composite, a targeted mask are often faster and 100% reliable by hand.

Two specific causes worth knowing:

  • Over-restrictive preserve clauses can cause no-ops (tested and verified). If almost everything is in the keep column and the one change is abstract, NB2 may read it as no change at all. Loosen the preserve block (“mostly as it is” instead of “exactly as it is”), or make the change more concrete. Real example: a post-apocalyptic city scene rebuild failed with an exhaustive preserve list and a tightly specified facade detail list — the same prompt rewritten conversationally with a looser “mostly” preserve block landed correctly.
  • IMAGE_SAFETY false positives return a 200-OK with no image, which the app surfaces as a no-op or a generic “explicit content” block — even on wholly innocuous content. Reroll; only change something after two or three repeats on the same prompt.

Note: a fresh JPEG re-export does not fix no-ops. Re-exporting fixes the tiled / stacked-output failure (a different bug — the frame comes back duplicated and stacked). Don’t conflate the two.

Operational rules

  • Prompt conversationally — not like a spec sheet. NB2 parses creative intent holistically. Directional, art-direction-style prompts outperform itemized spec lists. Use shared reference points that carry implicit information (“think Coruscant,” “like a buoy on water”) rather than exhaustive detail lists. Give the model a direction and let it work. Tested and confirmed: the city scene rebuild landed after switching from a blueprinted facade spec to a conversational art direction prompt.
  • One or two changes per turn. Stacking five edits into a single prompt causes the model to miss some. Make one change, confirm, then iterate.
  • Front-load the must-have element. If a specific detail keeps slipping (a logo position, an object, a line of copy), simplify the prompt and move that detail to the first sentence.
  • Use high-resolution source images. Low-res input produces low-res edits.
  • Iterate conversationally. NB2 holds prior turns — refine (“keep the composition, shift lighting to golden hour”) rather than re-prompting from scratch. This is the core efficiency: edit, don’t reroll.
  • Keep edit chains short to limit drift. Every edit re-derives the whole image, so proportions and identity drift cumulatively across a long chain (see Cumulative drift below). There is no confirmed prompt-level “anchor” that fixes this. The only reliable levers: keep the chain short, and audit against a fixed early hero frame — grid the outputs against it and regenerate hard failures rather than tweaking forward. Re-applying the full set of changes fresh onto the original (instead of editing the chain forward) is a plausible way to limit re-derivations to one, but it’s untested and collides with the one-or-two-changes-per-turn limit.
  • Positive framing. Describe what you want, not what you don’t (“empty street,” not “no cars”).
  • Web grounding is optional. Enable it only when real-world accuracy matters for that image.

Text and typography in edits

  • Enclose exact words in quotes: "FLASH DEAL".
  • Name or describe the font: “bold white sans-serif,” “Century Gothic.”
  • For text replacement, scope it: “Replace the text reading ‘Summer Sale’ with ‘Flash Deal’. Keep font style, positioning, and the rest of the image unchanged.”
  • Text-first hack: for generated (not replaced) text, converse to settle the wording first, then ask for the image.
  • Letter-by-letter errors still occur. For client-facing work, treat NB2 text as a draft and finalize typography in a design tool.

JSON vs. natural language

Not a blanket win for either. The split is the answer.

JSON helps when a prompt has competing style tokens — lighting, material, camera, atmosphere, and text all needing equal fidelity against a strong subject description. Structured fields isolate those tokens so the subject nouns don’t drown them. JSON also helps for batch repeatability, since fields are reusable across generations.

Natural language is fine when the edit has a single variable and a clean preserve block. JSON’s failure mode (subject nouns swamping style modifiers) doesn’t arise, so its benefit doesn’t either. A single-variable refinement is a wash between the two.

On the benchmarks: vendor claims of large JSON accuracy gaps (e.g. “92% vs 68%”) come from companies selling NB2 access, run on undisclosed test sets — treat as directional, not established. The one genuinely controlled A/B test found near-parity, with differences within normal LLM run-to-run variation.

Hybrid approach worth knowing: build the image definition in JSON as a structured creative brief, then convert it to a final natural-language prompt before sending.

Known weaknesses

  • Photorealism as whole-image conversion is a no-op. Asking NB2 to restyle the existing image — “make this CGI photorealistic” as the change — gets ignored. But a photorealism fidelity spec on your concrete changes (“render these changes UHD 8K photorealistic, no CGI”) works and should be included in edit prompts. See Photorealism in edits above — don’t conflate the two.
  • Hands. Overlapping fingers, gripped objects, unusual poses still produce errors. If hands appear at scale and aren’t the point, add an avoid clause.
  • Dense data tables/charts. Multi-row tables inside an image render with inconsistent alignment — labels appear, layout doesn’t hold. Use Pro, or design the chart separately.
  • Complex fluid physics. Splashes, caustics, close-range glass refraction land “good enough” but short of Pro-tier.
  • Face consistency. No model achieves 100% identity consistency across generations — the model re-interprets features each time. Reference images mitigate it far more than prompt wording does.
  • Cumulative drift across iterations. A documented NB2 limitation: across a long edit chain, body proportions, face, and object placement subtly and progressively shift. It’s architectural — each edit re-derives the whole image rather than carrying pixels forward, so tiny re-interpretations compound. Usually invisible turn-to-turn but obvious on an A/B of the first and last image in a long sequence. Confirmed mitigations: keep the chain short; audit against a fixed early hero frame (grid outputs against it, regenerate hard failures rather than tweaking forward). What does not work: correcting drift retroactively via prompt — feeding the original back in as a proportion reference and asking NB2 to pull a drifted figure back to it does not work (tested). Once proportions have drifted, the fix is Photoshop — a height scale and a liquify pass — not a prompt. The drift cannot be driven to zero; it’s probabilistic. Note: “anchor to a fixed frame to bound the drift” is intuitive but unproven as a prompt-level fix — treat short chains + audit + Photoshop correction as the only established workflow.

Worked examples — the register that works

These are real prompts that landed well. Note the pattern: plain imperative changes, lived-context world-building, a fidelity spec on the changes, and a casual stop-clause. No scaffolding, no tags (single image), no formal preserve block.

Multi-change wardrobe edit:

Make her bandanna a flat white thin cotton with slightly frayed edges. No patterns. No color.
Make her field jacket a flat military grey heavy duty fabric. There is a large frayed tear in the shoulder. The fabric should be grimy, with dirt worked into the weave of the fabric and have random grease/oil stains. This jacket is old. She stole it from a corpse.
Make her belt and belt pouches, rucksack, and shoulder straps OD green canvas. The canvas is sun-bleached, dirty, and stained. The buckle and grommets and metal fasteners are old and worn. They aren't just old surplus, they're third-hand. Maybe fourth.
All elements should be rendered UHD 4K photographic quality. No CGI or digital art effects. Every detail should be photorealistic.
That's it. Those are the only changes I want.

Diagnose-then-redirect realism pass:

This looks like a model cosplaying a survivor. It doesn't look realistic.
The young Southeast Asian woman is an orphaned scavenger. She's a young teen, but her skin should look like she works out in the sun and harsh elements. No makeup. No healthy glow. She's hungry and cold and lives three feet from an open sewer in the slums.
Her clothing and gear have cosmetic dirt and grime and stains and wear and tear right now. Make them look like they've been through hell. Like she's a war refugee.
All elements should be rendered UHD 4K photographic quality. No CGI or digital art effects. Every detail should be natural and photorealistic.
That's it. Those are the only changes I want. Don't change the pose or framing. Definitely don't touch the background. Don't change her pose or the direction she's looking. Don't wash out her skin tone. She should have a warm brown Southeast Asian complexion with golden undertones. Don't make her look older. Just make her look like a real fourteen-year-old in a war zone.

Single-image targeted color/tone fix:

Remove the violet/purple highlights from her hair. It should be a natural dark brown, almost black.
Her braided cord bracelet should be faded brick-red and ocher.
Her skin tone should be Southeast Asian warm tanned brown with golden undertones.
That's it. Don't make any other changes or additions. All changes should be done at UHD 8K photorealistic fidelity. No CGI or digital art.

Sources

  • Google Cloud Blog — Ultimate prompting guide for Nano Banana (Mar 2026)
  • fal.ai — How to Use Nano Banana 2 and the Nano Banana 2 Edit model page
  • Google Developers / Vertex AI — Gemini 3.1 Flash Image documentation
  • Session testing (primary, supersedes community advice where they conflict) — the casual-language-over-spec-sheet principle, photorealism fidelity-spec vs. conversion distinction, lived-context world-building language, diagnose-then-redirect opener, single-vs-multi image tagging, no-op diagnostic ladder, IMAGE_SAFETY false positives, over-restrictive preserve block loosening