Recraft v4.1 Text-to-Image Prompt Recipes for Developers

Why Prompt Recipes Beat One-Off Prompts

Every team that calls a text-to-image API eventually hits the same wall: the prompt that produced a great image lives in a chat log, a throwaway script, or someone's notes app. When a product requirement shifts — "same illustration, but photographic" or "add a headline in the image" — nobody knows which words mattered, so the prompt gets rewritten from scratch and the output changes in unpredictable ways.

A prompt recipe fixes that by treating the prompt as a small, parameterized document. One skeleton, a handful of swappable blocks, and a short list of constraints. Changing style becomes a single-field edit rather than a full rewrite, which means you can diff prompts, review them in pull requests, and reason about why an output changed.

Recipes also make quality regressions debuggable. If an image suddenly looks wrong, you can bisect: was it the subject block, the style block, the layout instructions, or the negatives? With one-off prompts, the answer is usually "everything."

This guide walks through a concrete skeleton for Recraft v4.1 text-to-image and gives copy-paste recipes for the two families developers reach for most: illustration and photography. The same structure extends to layout control, in-image text, and negative lists.

What a recipe actually contains

Think of each recipe as four pieces:

• A fixed skeleton — the ordered blocks every prompt in your codebase shares.
• Swappable style vocabulary — the words that move an output between illustration and photography.
• Constraint clauses — layout, aspect, text rendering, and exclusion instructions.
• A version tag — so a prompt in production can be traced back to the exact revision that generated an asset.

None of this requires special tooling. A JSON file per recipe, checked into the repo next to the code that calls the API, is enough.

The Prompt Skeleton: Blocks That Stay and Blocks That Change

The skeleton below is deliberately boring. That is the point — the stable parts should never need editing, so attention goes to the parts that change.

[SUBJECT]        what is in the image, described plainly
[STYLE]          medium and rendering vocabulary
[COMPOSITION]    framing, camera or layout, aspect
[CONSTRAINTS]    text rendering, palette limits, do-not rules

Which blocks stay, which get swapped

• SUBJECT — stays. This is the only block your product logic should normally parameterize (a product name, a scene description from user input).
• STYLE — swaps. Illustration and photography differ almost entirely here.
• COMPOSITION — mostly swaps, but the shape of the instruction stays the same (framing, then aspect).
• CONSTRAINTS — partially shared. Negative lists and "no text unless specified" rules tend to be global; text-rendering instructions are per-request.

A minimal template as data

{
  "recipe_id": "product-hero",
  "version": "3",
  "subject": "a ceramic coffee mug on a plain surface",
  "style": "{{style_block}}",
  "composition": "centered, generous negative space above the subject, square aspect",
  "constraints": ["no text in image", "no watermark"],
  "negatives": "{{negative_list_v2}}"
}

The {{style_block}} placeholder is the seam. Everything else is either shared across recipes or supplied by the caller. When you add a third style later — say, isometric 3D — you add a style block, not a new prompt file.

One practical note: keep the block order stable across every recipe. Models are not guaranteed to be order-sensitive in a documented way, but your team is. Consistent ordering makes prompts comparable and makes side-by-side review meaningful.

Illustration Recipes: Flat, Vector and Editorial Looks

Illustration recipes are where most teams start, because illustration tolerates simplification well — which makes it good for testing the skeleton without fighting realism.

Flat illustration

[SUBJECT] a developer workspace with a laptop, notebook and coffee mug
[STYLE] flat vector illustration, solid fills, no gradients, bold simple shapes, limited four-color palette, clean geometric forms
[COMPOSITION] centered composition, even margins, square aspect
[CONSTRAINTS] no text in image, no shadows, no textures

What drives this look: flat, solid fills, no gradients, bold simple shapes. Each of those words is doing work. Drop "no gradients" and you will often get soft shading creeping in.

Vector-style iconography

[SUBJECT] a single shield icon with a checkmark
[STYLE] minimal vector icon, uniform stroke weight, rounded line caps, two-tone, high contrast on plain background
[COMPOSITION] centered, icon fills most of the frame, square aspect
[CONSTRAINTS] no text, no background scenery, no gradients

Icon prompts benefit from explicit scope words — single, uniform stroke weight — because without them you tend to get a small scene instead of a glyph.

Editorial illustration

[SUBJECT] a person reviewing charts on a large screen
[STYLE] editorial illustration, muted palette, subtle grain, hand-drawn line quality, slightly abstracted human figures, magazine feature style
[COMPOSITION] subject offset to the right, breathing room on the left, landscape aspect
[CONSTRAINTS] no text in image, no photorealism, no logos

Editorial looks live in the middle ground: more texture and character than flat vector, but still clearly not photographic. The pairing of muted palette with subtle grain is what keeps it from drifting toward either extreme.

Tuning tip: change one style adjective at a time. Swapping "muted palette" for "vivid palette" is a real experiment; swapping five words at once is not.

Photography Recipes: Realistic, Studio and Lifestyle Framing

Photography recipes use the same skeleton with different vocabulary. Notice that the subject block barely changes — that is the payoff of templating.

Clean studio product shot

[SUBJECT] a ceramic coffee mug on a plain surface
[STYLE] professional studio product photography, soft diffused key light, gentle falloff, neutral background, sharp focus, realistic material detail
[COMPOSITION] centered, slight three-quarter angle, generous negative space above, square aspect
[CONSTRAINTS] no text in image, no props, no harsh reflections

Photography vocabulary clusters around light (soft diffused, falloff), optics (sharp focus, depth of field), and material truth (realistic material detail). Illustration vocabulary clusters around shape and fill. That contrast is the whole difference between the two recipe families.

Environmental lifestyle

[SUBJECT] a person working at a wooden desk near a window
[STYLE] candid lifestyle photography, natural window light, shallow depth of field, warm neutral tones, realistic skin and fabric texture
[COMPOSITION] over-the-shoulder framing, subject left of center, landscape aspect
[CONSTRAINTS] no text in image, no visible brand marks, no exaggerated saturation

Candid and natural window light pull the output away from studio polish. If the result looks too staged, that is usually a composition problem as much as a style one — adding "over-the-shoulder framing" does more than adding more adjectives.

Converting an illustration recipe to photography

Given a working illustration recipe, the conversion is mechanical:

1. Replace the entire [STYLE] block with photography vocabulary.
2. Adjust [COMPOSITION] only where framing differs (angles matter more in photography).
3. Keep [SUBJECT] byte-for-byte identical.
4. Keep global negatives; drop illustration-specific ones like "no gradients" that no longer apply.

If the photographic result invents or drops elements from the subject, the subject block is probably underspecified — fix it there rather than adding compensating style words.

Controlling Layout and Text Rendering

Layout and text are the two things developers most often hope the model will infer, and the two things most worth stating explicitly. Treat them as their own prompt blocks, separate from style.

Positional language that actually constrains

Vague: "a banner image for a landing page."

Explicit:

[COMPOSITION] landscape 16:9 frame; subject occupies the right two-thirds;
left third is empty open space suitable for a headline; horizon line at
lower third; nothing enters the left third

Three habits make positional instructions stickier:

• Name the frame before describing placement ("landscape 16:9 frame").
• Reserve zones explicitly and say nothing enters them. Empty space is not the default.
• Anchor to thirds rather than words like "slightly off-center," which are not measurable.

Text rendering

When you want text in the image, isolate it as a block and quote the exact string:

[TEXT] render exactly the words "Ship faster" in a bold sans-serif,
placed in the reserved left third, vertically centered, single line,
high contrast against a plain background. No other text anywhere.

Points that reduce iteration:

• Quote the literal string — never paraphrase it in the prompt.
• Say "exactly" and "no other text" — otherwise stray lettering appears in corners or on props.
• Specify line count ("single line") because wrapping is otherwise a guess.
• Specify contrast context ("against a plain background") so the text has something to sit on.
• Keep text out of the [STYLE] block entirely; mixing them makes both harder to tune.

If a request needs precise, multi-element typography, treat generated text as a starting point and plan for a real text layer downstream. Prompt-level text control is good for short headlines and labels, not for dense copy.

Negative Lists: What to Exclude and How to Version Them

A negative list is the cheapest quality control you have. Instead of describing what you want, you name the failure modes you refuse to accept.

Categories worth excluding

Organize negatives by category so you can add to them without creating contradictions:

• Text artifacts — stray lettering, gibberish glyphs, watermarks, signatures.
• Composition artifacts — cropped subjects, cut-off limbs, duplicated elements, cluttered edges.
• Rendering artifacts — blur, banding, oversaturation, harsh HDR look, plastic skin.
• Content hygiene — brand logos, recognizable trademarks, real people's likenesses.
• Style drift — photorealism in an illustration recipe, illustration in a photography recipe.

That last category is the one teams forget. If your illustration recipe keeps drifting realistic, an explicit negative is often more reliable than piling on style adjectives.

Keep it short and non-contradictory

Long negative lists backfire. If a negative conflicts with a positive instruction, results get unstable and you cannot tell which clause won. Two rules:

1. Never negate something you asked for. If the composition block requests shadow for depth, do not also list "no shadows" globally.
2. Prefer specific over sweeping. "No watermark" is actionable; "no bad things" is noise.

Version negatives alongside prompts

Negatives change behavior for every recipe that references them, so they need the same traceability as prompts:

{
  "negative_list_id": "global-v2",
  "entries": ["watermark", "signature", "stray text", "cropped subject", "duplicated elements", "oversaturated colors"]
}

Reference the list by ID from each recipe, and bump the ID when you edit it. When output quality shifts after a deploy, "did the negative list change?" becomes a one-line check in the diff instead of an investigation.

Comparing Real Outputs Before Shipping

A recipe is a hypothesis until you have looked at real outputs. The comparison workflow below is deliberately lightweight — it should take minutes, not a sprint.

The workflow

1. Freeze everything except one variable. Same subject block, same composition, same negatives, same seed if the API exposes one. Change only the style block.
2. Generate a small matrix. Two or three style variants across two or three representative subjects is usually enough to expose a bad recipe.
3. Review side by side, not in sequence. Sequential review invites recency bias — the last image looks best because it is freshest.
4. Score against the requirement, not taste. Write down what the asset is for (hero banner, icon set, editorial header) and check the specific properties that matter: reserved space actually empty, no stray text, style drift absent.
5. Promote deliberately. Only the recipe revision that passed review goes into product code, tagged with its version.

What to look for

• Consistency across subjects. A style block that works for one subject and collapses on another is not ready.
• Constraint adherence. Did the reserved left third stay empty? Did the exact quoted string appear once?
• Failure clustering. If the same artifact shows up across variants, it belongs on the negative list, not in a style tweak.

Keeping it in the repo

Store the recipe JSON, the negative list version, and the review notes together. When someone asks six months later why the hero images look the way they do, the answer is a commit, not a memory.

Once a recipe survives this loop, switching between illustration and photography for a given subject is a one-field edit — exactly the maintenance property the skeleton was built to give you. Run these recipes against Recraft v4.1 text-to-image through one unified API and keep every prompt revision versioned next to the code that calls it.