Text Baked Into the Image vs Text Stamped Over It

"Add text to the slideshow" sounds like one request. It's actually a fork in the road with two genuinely different outputs on either side, and picking the wrong one either wastes a generation or produces the wrong aesthetic entirely — a stamped caption when you wanted integrated type, or a rendered quote card when you wanted something you could edit the wording on in ten seconds.

Baked in: the image model draws the words

The first path renders the caption as part of the image itself — the same pass that draws the scene also draws the letterforms, so the type sits inside the picture with its own lighting, perspective, and integration into the composition, the way a designed quote card or an infographic slide looks rather than a photo with a caption slapped on.

This is what create_slideshow_caption_in_image does mechanically: it dispatches each slide to an image model — Nano Banana Pro by default, or GPT Image 2 — with the caption as part of what that model is asked to render. Two things about how it actually behaves matter for planning around it:

• It's asynchronous. The tool returns before the images are ready, immediately handing back a slideshow_generating status and a slideshow ID. Each slide finishes over the following roughly 30–90 seconds as the image model completes it, delivered by webhook rather than in the same response. Plan for a short wait, not an instant result.
• It must not be chained with other text or image tools on the same slideshow. More on why below — it's the single most important rule in this whole comparison.

Baked-in type is the right call when the typography is the design — quote cards, dense infographic-style slides, anything where the words are meant to look drawn rather than placed.

Stamped on: a text layer over a finished image

The second path works in the opposite order: get the image first, then apply text as a layer on top of it. add_text_overlay does exactly this — it takes a slideshow that already exists and applies overlay text to its images, either one overlay style auto-expanded across every slide, or a distinct overlay per slide when you pass one for each image in the set.

This path trades integration for control. Because the text is a separate layer rather than something an image model interpreted and rendered, changing the wording later doesn't mean regenerating the underlying image — the caption updates without touching the picture beneath it. That makes it the better fit for anything caption-driven: tutorial steps, talking points, a carousel you expect to A/B test with different wording over the same visual, or any format where the picture is doing one job and the words are doing a separate one.

The practical difference shows up most clearly the second time you need to change something. A wording tweak on a baked-in caption means describing the change and letting an image model re-render the whole slide, hoping the rest of the composition holds steady around the new text. The same tweak on a stamped overlay is a text edit — the picture underneath never moves. If a slideshow is going to get revised more than once, that difference compounds fast.

The double-render trap

Here's the mistake both paths independently warn against: chaining them. create_slideshow_caption_in_image's own behavior is explicit that it should not be chained with create_slideshow, search_pinterest, other image-generation tools, or add_text_overlay — doing so "would double-render text."

The failure is exactly what it sounds like. If an image model already rendered your caption into the picture, and then a text-overlay pass stamps a second layer of text on top of the same slide, you get two competing text layers on one image — either a visually duplicated caption, or two different pieces of text fighting for the same space, neither placed with the other in mind. Both tools work correctly in isolation. Run in sequence on the same slideshow, they actively conflict.

The rule that avoids it entirely: decide baked-in or stamped-on before you generate, not after. This isn't a "try one, then layer on the other if it's not quite right" situation — it's a fork you commit to at the start, because there's no clean way to add the second approach on top of the first once slides exist.

That commitment is per-slideshow, not permanent. Nothing stops the same account from running baked-in type on its quote-card series and stamped overlays on its tutorial carousels — the constraint is narrow and specific: don't run both tools against the same set of slides. Mixing approaches across different content types on the same account is normal and often correct; mixing them within one slideshow is the only combination that actually breaks.

Picking the right one for the format

A few honest heuristics, since "which one is better" depends entirely on what the slideshow is for:

• Quote cards, aesthetic carousels, infographic-style posts → baked-in. The type is supposed to look designed, not applied, and that's specifically what an image model rendering it in the same pass produces.
• Tutorial or how-to carousels, talking-point breakdowns, anything you'll want to reword → stamped-on. The iteration speed on wording matters more than integration, and a text layer is trivial to edit where a rendered caption means a full slide reroll.
• A/B testing the same visual with different copy → stamped-on, without question. Baked-in type means a fresh image generation per variant; a stamped overlay means the same underlying picture with swapped text, which is both faster and cheaper to test with.
• Dense, data-heavy slides where layout and text need to interact tightly (numbers next to specific chart elements, labels pointing at specific regions) → baked-in, since an overlay pass has no awareness of what's actually in the image beneath it.

A real walkthrough for each path

Baked-in: ask the agent to generate a slideshow from a prompt and specify that the caption should be rendered into the image itself — something like "make a slideshow of five brand-tip quote cards with the text designed into each image." Expect the slideshow_generating status back immediately, then ask to see it on the next turn once slides have completed via webhook.

Stamped-on: generate or assemble the slideshow first, then separately ask to add text to the slideshow images — either one consistent caption style across every slide, or specific wording per slide if each one needs different text. Because this is a distinct step after the images exist, you can iterate on the wording repeatedly without touching the underlying pictures at all.

Either path benefits from settling on the type treatment before generating: a font and style that matches the account's look, chosen once from the available font library rather than re-decided slide by slide. For the baked-in path that means describing the type style in the prompt itself; for the stamped-on path it means picking the overlay style up front, since that's the one applied consistently across the set.

The decision, restated

This isn't really a comparison of which tool is better — they solve different problems. Baked-in type is a design decision made once, at generation time, that you live with. Stamped-on type is a decision you can keep revisiting. Neither is the default; the format decides which one you need, and the one rule that survives either choice is not letting both touch the same slideshow. Browse the full slideshow format options before defaulting to whichever path you used last time — the two aren't interchangeable, and the right one changes with what the carousel is actually for.