How to put a QR code in a video so it still scans

Last updated 2026-09-10 · 8 min read

What is the short version?

A QR code is a grid of hard-edged squares, which is the worst possible thing to put through a scaling pass and a video encoder. It comes out soft, the squares bleed into each other, and a phone that would read the original will not read the video.

1. Go to Vizard Agent with the code file.
2. Ask for it placed at exact pixel size, not scaled.
3. Ask it to read the code back off the render.

What do you need before you start?

The code itself, at a decent size, and somewhere for it to live in the frame. Vizard Agent needs the original file rather than a screenshot of one, because a screenshot has already been through one resampling pass before it arrives.

• The code file. PNG or SVG, not a screenshot.
• Where it goes. Usually a closing card.
• How long the card runs. Scanning takes seconds.
• What sits behind it. Plain beats busy.
• The output resolution. It decides the usable size.

What do you type into Vizard Agent?

Ask Vizard Agent for the placement in pixels rather than in proportions. This is the one piece of on-screen artwork where "make it look right in the layout" is the wrong instruction, because the code either survives at a size it can be drawn cleanly at, or it does not.

Prompt

Variants worth knowing:

• "At exact pixel dimensions." The instruction that matters.
• "Keep clear margin." The quiet zone is part of the code.
• "Read it back from the render." Proof, not assumption.

What does Vizard Agent actually do?

Here is the pattern across several real ads that ended on a card with a code, a logo and a store badge. The important thing is that the code is treated as artwork with a fixed size rather than as an element in a layout.

1. Checks the file's format and real dimensions.
2. Sets the code to an exact pixel size for the output.
3. Builds the card as a transparent overlay at full resolution.
4. Composites it rather than scaling it into place.
5. Keeps the quiet margin clear of other elements.
6. Puts it on a plain area of the card.
7. Measures how long the card is visible.
8. Renders a frame from the finished video.
9. Tries to read the code from that frame.
10. Enlarges or simplifies if it does not read.

Step three is what preserves the edges. Building the whole card as an overlay at the output's own resolution means the code is drawn once at the size it will be shown, instead of being scaled by a compositing step that softens every boundary in it.

Step nine is the only test that counts. A code that looks fine in a still frame at 100% can still fail on a phone pointed at a screen, so reading it back from the actual render is the check that separates a working card from a decorative one.

Step seven is the constraint people underestimate. A phone needs a couple of seconds to find and lock onto a code, and a card that flashes past in one is decoration whatever its resolution.

What does the result look like?

An end card where the code has crisp edges, clear space around it, and enough time on screen for somebody to get a phone out. Vizard Agent will have read it back off the render, so you know it worked at least once.

If it did not survive, Vizard Agent tells you and suggests making it larger or the background plainer.

When does this not work well?

Some formats simply do not have the pixels. A dense code carrying a long URL, shown small in a vertical video that a platform will re-encode again, may not survive whatever you do — the answer there is a shorter link or a spoken one.

• Very dense codes. Long URLs need more squares.
• Small output resolutions. There may not be room.
• Platform re-encoding. It happens after you deliver.
• Busy backgrounds. Contrast matters as much as size.
• Fast-moving cards. Motion blur destroys the grid.

How do you fix a result that came back wrong?

Say whether it failed on the render or on a real phone. Those are different failures — one is a rendering problem Vizard Agent can fix, the other is usually about size, time or the platform's own compression.

• "It will not scan from the frame." Larger, or plainer behind.
• "It scans on my screen, not on TikTok." Re-encoding; go bigger.
• "There is no room." A shorter link makes a simpler code.
• "It is too big now." Trade against the card's other elements.

How does Vizard Agent compare to doing it yourself?

By hand a code gets dropped into a layout and scaled to fit, which is exactly the operation that breaks it, and nobody tests it until the ad is live. The quiet margin is usually the first thing a designer crops off.

Common questions

Why does it stop working on video? Scaling softens the squares and compression blurs the edges. Vizard Agent avoids the first and checks for the second.

What size should it be? As large as the card allows. Vizard Agent will say the minimum.

Can it use an SVG? Yes, and Vizard Agent will rasterise it at the exact size needed.

Does the background matter? A lot. Vizard Agent will suggest a plain area behind it.

How long should the card hold? A few seconds at least. Vizard Agent measures the visibility.

Can it check the code reads? Yes, off a rendered frame. That is the point of the pass.

Will it survive the platform's re-encode? Larger and plainer survives better. Nothing is guaranteed.

Can it generate the code? Give Vizard Agent the file; generating it is a separate job.

What about a code over footage? Possible, but Vizard Agent will tell you a plain card is far more reliable.

Can it animate in? Yes, but Vizard Agent will keep it still and full size for the scannable stretch.

Does a shorter URL help? Considerably. Fewer squares means bigger squares, and Vizard Agent will say when yours is too dense.

Can I put a logo in the middle? Many codes tolerate it. Vizard Agent will read it back to check.

What about vertical video? Less width, so Vizard Agent will push for a simpler code.

Why did mine look fine but not scan? Because a still frame at full size is not the same as a phone at arm's length.