Those three moves are what make these scene style prompts work on Gemini image models, and they are what most published prompt lists leave out. A prompt that names a style, a mood and a list of adjectives gets you a plausible image that ignores your actual brief. Below is the structure, the placeholders, a worked example, and the checks that catch a bad render before you spend more time on it.
Model names and features in this area move quickly. Check the current documentation for the model you are using before you rely on any specific parameter mentioned here.
What nano banana prompts do differently
Gemini image models are described as reasoning models rather than pure samplers, which shows up in practice as a preference for instructions written like a scene description instead of a tag soup.
That preference has three consequences. The model handles a described scene and its constraints better than it handles a comma separated style list. It responds to an explicit instruction about what to preserve across an edit. And it takes natural language directions, such as keep the pose, as seriously as a setting name.
The practical version is short. Scene, camera, keep, change.
Scene first: describe the frame before the subject
Describe the situation before you describe the thing in it. A model reading a scene understands relationships, so the person, the surface and the light have to exist in the same description.
Write it in this order: who or what is in frame, where they are, what they are doing, what the frame contains around them, and what the frame must not contain. That last clause matters, because an unmentioned object is an object the model may add.
Scene: [who or what] [doing what] in [place], at [time of day]. The frame contains [two or three named elements]. The mood is [describe in plain language, not as an adjective list]. Do not include [text, logos, extra people, clutter, or anything you must not see].
Name the camera and the light
Camera terms do specific work, but only the ones you can name precisely. Focal length sets how much the background compresses, camera height sets the power dynamic in the frame, and light direction sets which side of the subject carries detail.
Camera: [lens and framing, for example 50mm at eye level, medium shot, subject centred slightly left]. Light: [direction and quality, for example low window light from camera left, soft shadows, no fill]. Colour: [describe the palette in a sentence].
Avoid stacking six terms. Two that you understand beat six that sound professional, because you cannot tell which one produced the result.
Keep versus change: the instruction that controls drift
This is the part that distinguishes an editing prompt from a generation prompt. Name what is locked and what is allowed to move, in two separate lines.
Keep unchanged: [face, hairstyle, hand position, the existing background, the garment cut, the colour of the jacket]. Change only: [the single element you are editing]. Everything not named in the change line stays as it is in the source image. Do not restyle, do not relight, and do not improve anything you were not asked to change.
Fill in these details
- Scene: the situation in one sentence, written before any styling.
- Framing and lens: what the camera sees and how close it is.
- Light: direction, hardness and time of day. One source is usually enough.
- Keep list: the features that must survive the render, named as things a viewer can identify.
- Change line: exactly one element. If you can write two, split them into two edits.
Adaptation note: if you are generating rather than editing, keep the scene and camera blocks and drop the keep list, because there is no source to preserve.
Worked example: one product photo, three edits
Suppose a small maker has a photo of a ceramic mug on a kitchen counter and needs three variants for a listing page.
| Prompt block | Value used |
|---|---|
| Scene | The same ceramic mug on the same counter, unchanged placement, morning light |
| Camera | 50mm, slightly above table height, mug filling the frame |
| Light | Soft daylight from a window to the left, no harsh shadows |
| Keep | Mug shape, glaze colour, handle position, counter, wall, shadows |
| Change | Replace the plain background with a pale grey plaster wall |
Three variants follow the same pattern: change only the surface behind the mug, keep the contact shadow so the object still sits on the counter. The contact shadow is the detail most people forget, and losing it is the reason an edited product shot looks pasted on.
How to check a nano banana prompt before you render
1. Read the change line on its own
Cover the rest of the prompt. If the change line names two things, the render will negotiate between them. Go back to the source image and decide which single change you would accept if the other one failed.
2. Confirm the keep list names visible features
"Mood unchanged" is not a keep instruction. "The mug handle stays on the right side and the glaze stays speckled" is. Every keep item should be something you could point at in the image.
3. Look at what is in the frame, not just the subject
Check the edges of the frame for objects that arrived uninvited, and check the light for a direction that flipped. Both are common in edits where the change line was too broad.
Common nano banana pro prompt guide mistakes
- Listing styles instead of describing a scene. A list of five style words gives the model nothing to place in a frame.
- Naming a camera you cannot explain. You will not be able to tell which term to change when the result is wrong.
- Asking for text in the render. See the library's guide to text in generated images for why this fails and what to do instead.
- Changing two things in one edit. Split it. Two changes in one pass is the most common cause of a result you cannot use.
- Trusting the first render. Fix the prompt, not the image. If you are correcting the image by editing it again, you are describing the correction badly.
- Assuming yesterday's settings. Feature support for these models changes between releases, so verify the current behaviour in the documentation.
Frequently asked questions
Do nano banana prompts work better than short prompts?
For describing a scene or making an edit, longer structured prompts tend to give more control, because the structure separates the scene, the camera and the change. For pure visual exploration, a short prompt is fine and faster to iterate.
What is the keep versus change trick?
It is naming the features that must stay identical in one line and the single element to alter in another. Models treat an explicit keep list as a constraint rather than a preference, which reduces drift in the untouched parts.
Can one prompt produce a whole consistent set?
It can produce variation inside one render, but a set that must match across separate renders needs an identity block and fixed settings, which is a separate technique from editing.
Render one scene, then add the camera
Take the task you actually need and write three lines: scene, camera, change. Render once, then add only what the result proves you need. For the reasoning behind style and control on other image models, read the FLUX prompting guide.