Text on AI Video: Overlay Rules That Survive Publishing

Text burned into a video is the only part of it you can never change. Everything else has a second chance — the caption gets edited, the thumbnail gets swapped, the product page gets rewritten. Pixels do not. Once a clip is published with a word on it, that word is there for as long as the post is.

I run three generated videos a day across a fashion store and six country accounts, and almost every rule below came from getting it wrong first. Here is what I would tell anyone putting text on AI-generated video.

Never put a price on screen

This is the one that cost me the most, and it is the one people push back on hardest, because a price on the creative genuinely does lift click-through.

The problem is that prices move. Sales start, seasons turn, landed costs change, currencies drift. A clip with "399" burned into frame four is accurate for about three weeks, and then it is a promise you are still publicly making and no longer keeping. On a scheduled post that goes out weeks after it was made, it can be wrong on the day it first appears.

And you cannot fix it. You can delete the post, which throws away whatever reach it built, or you can leave a stale price running. Neither is good.

The price belongs on the product page, where it updates itself. The video's job is to make someone want the thing; the caller-to-action's job is to get them to a page where the current price is. My captions end with an arrow and the product URL and nothing else.

If the text does not fit, add rows — never shrink the font

The most common failure I see in generated-video pipelines is text running off the edge of the frame, and the instinctive fix — make the font smaller — is the wrong one.

Small text on a 9:16 clip is unreadable on the device it will actually be watched on, and it survives platform compression worst of all. A caption that has shrunk to fit is a caption nobody reads, which is the same as no caption at all, except you paid for it.

The right fix is to wrap onto more rows. Two rows, or three if you need them. Keep the type size where it is legible and let the block get taller.

This bites hardest when you translate. My source cards are written short in one language, and translation inflates them — the same line can run 30–40% longer in another language and sail straight off the edge. I once shipped fifteen cards across fifteen folders with text hanging off the frame, and the distribution told the story: the languages with the longest words had the most breakages, and the source language had none at all. That is why it survived every check — the version I was looking at was fine.

So the rule is mechanical, not aesthetic: measure the rendered width of every card in the actual output space, wrap it to the fewest rows that fit, and only consider shrinking the type if three rows still overflow. A card that cannot fit at all should stop the build, not get burned anyway.

Keep everything readable inside the middle of the frame

Vertical video is not the size it looks. The platform draws its own interface over your clip, and the parts it covers are exactly where people put text.

The bottom of the frame carries the caption, the username, the audio strip. The right edge carries the button rail — like, comment, share, profile. On a 1080×1920 clip, assume the bottom fifth is gone and a strip down the right side is gone too.

Anything that must be read goes in the middle band, roughly between 12% and 78% of the frame height, and centred rather than aligned right. This applies to end cards especially, which is where people put the thing they most want read — the URL, the handle, the offer — and where it is most reliably covered.

Test it the honest way: export the clip, pull the last frame, and look at it with the platform's overlay in mind. Do not trust the editor's preview, which shows you a clean rectangle nobody will ever see.

Read the pixels, not the exit code

This is the rule I would put above all the others, because it is the one that let the worst mistakes through.

When a generation pipeline has a language model somewhere in it — writing the cards, translating them, fixing them — its scaffolding can end up in the output. I have shipped clips with the model's own instructions burned on screen: a bracketed placeholder that was meant to tell it the format, a section marker that was supposed to separate the caption from the cards. Eleven clips went out that way, and every single step in the pipeline reported success, because every step only checked whether the previous command exited cleanly.

An exit code tells you a process finished. It tells you nothing about what is in the frame.

So verify the artifact, twice, in two different ways:

A deterministic gate on the text. Before anything gets burned in, run the string through checks that cannot have an opinion: no angle brackets, no hash markers, no bare numbers where a price would be, real words in the target language, length within the frame. This catches scaffolding and it catches the empty string, and it never gets bored.

A frame you actually look at. Extract one still per card from the finished file and look at it. Not the source text — the rendered pixels. This is the only check that catches a font that failed to load, a character the renderer could not draw, or text sitting in the covered zone.

One practical trap when you extract that frame: seek on the output, not the input. Seeking before the input file resets the timestamps, so a card that lives between 0.4 and 3.2 seconds never appears, and it looks exactly like the burn failed when it did not. I have wasted a good hour on that one.

Fix by rebuilding, never by editing the description

When you do catch a bad card, there is only one honest repair: go back to the raw render and burn it again, writing to the same filename so anything already scheduled picks up the fix.

The tempting shortcut is to edit the text file that says what the card contains, so the records look right. That does not change a single pixel. It just makes the wrong video harder to find later, because now the paperwork disagrees with the footage and the paperwork is what anyone will check.

Which leads to a broader point about keeping the raw renders. If you have thrown away the source and only kept the finished cut, a clip with bad text is not repairable — it can only be deleted and remade from scratch. Keep the raws for anything still in rotation. Disk is cheaper than a re-render, and much cheaper than a clip you have to pull.

What actually belongs on screen

Having ruled things out, here is what earns its place.

Something the video cannot say. The size range. The colours it comes in. The material. Information that answers the question the viewer was about to not bother asking.

Two cards, not six. Text competes with the product for attention, and on a fifteen-second clip you have room for the product or for a wall of words. I use two short cards and let the footage do the rest.

Nothing the model generated itself. Ask an image or video model for text in frame and you get something that looks like letters from a distance and is garbled up close — worse the smaller it is. Brand names especially. Burn text in afterwards where you control the font, or make it a physical object in the scene, which models render far more convincingly than they render lettering.

The platform's AI label, separately. A line of text saying the clip is AI-generated is not the same as the platform's actual disclosure flag, and only the flag counts. Set the real one and keep the text line as a courtesy, never as your only compliance. More on that in AI video disclosure rules.

The short version

No prices, ever. Wrap to more rows instead of shrinking the type. Keep readable text inside the middle band, away from the bottom fifth and the right rail. Gate the words deterministically before the burn and look at a real frame after it. Repair from the raw render, not from the notes. And keep the number of cards down, because the product is the point and the text is only there to answer what the picture cannot.

If you are working out the generation side rather than the finishing side, the AI video prompt guide and AI subtitle generator cover the parts this guide assumes.

Looking for something else? Browse all AI video guides in one list.

Looking for something else? Browse all 110 AI video guides in one list.

If you are building a generated-video pipeline and want the finishing and verification side worked out properly — gates, wrapping, safe areas, repairs — that is exactly what we do together. Join the AI Video Generator community on Skool and bring your pipeline.