Design
Animated QR codes
An animated QR code is safe when every single frame decodes to the same payload on its own. Animate colours, module shapes or the background — never the data, and never leave a mid-transition frame that breaks modules. Export as GIF, APNG or video, and decode a sample of frames before publishing.
The one rule
A phone camera does not watch your animation — it grabs individual frames, tens of milliseconds apart, and tries to decode whichever one the shutter caught. So the safety rule is absolute: every frame must independently decode, and decode to the same payload. If that holds, animation costs nothing technically. If any frame fails, the code scans intermittently and the user experiences a code that "sort of works", which reads as broken.
Safe to animate, unsafe to animate
| Safe | Unsafe |
|---|---|
| Module and background colours, provided every frame keeps ≥ 40% luminance difference, dark on light | Changing the payload between frames — the phone acts on whichever frame it caught |
| Decoration outside the quiet zone: frames, CTA text, glows | Moving the code's position or scale while people aim (see QR codes on video) |
| Module shape morphs that keep each module's centre solid — rounded to square, say | Transitions that pass through non-decoding intermediate frames |
| A gentle sheen or pulse in brightness, within the contrast rule | Blinking — any frame where the code is absent or faded below contrast |
The subtle trap is the tween. Both end states of a styling transition can decode while the in-between frames — modules mid-morph, colours mid-fade through grey — do not. Users then see scan latency double or triple as the camera waits for a good frame, the mechanics of which are covered in why some codes scan instantly. The fix is editorial, not technical: cut between states rather than tweening, or keep tweens so short (2–3 frames) that a failed grab retries into a clean frame immediately.
Verifying an animation
Export, then decode a sample of frames, including mid-transition ones — not just the resting state. Extract frames with any video tool and run each through the validator, or script it against the API:
ffmpeg -i animated-qr.gif frames/f%03d.png
# then POST each frame to https://useqr.app/api/v1/decode
Every frame should return the identical payload. One failing frame means redesigning that moment of the animation, not shipping and hoping.
Formats
GIF is universal and fine for flat-colour codes — but watch dithering, which speckles solid modules with mixed pixels. APNG keeps full colour depth for gradients. MP4/WebM suit digital signage and livestream overlays, where video pipelines expect video. None of this applies to print, which gets exactly one eternal frame.
When animation earns its place
On screens, motion buys attention: a subtle pulse in a signage loop or stream overlay draws the eye to the code far better than a static corner block. It costs scan time the moment it violates the frame rule, and it adds nothing once the viewer has decided to scan — from that point the animation is pure risk. The honest default: animate the surroundings (frame, glow, CTA), keep the code itself rock-still, and leave it on screen long enough to be used — see minimum on-screen duration.
FAQ
Can a QR code be animated?
Yes, safely, if every single frame decodes on its own to the same payload. Cameras decode from individual frames, so any frame that fails — mid-transition, faded, or blinked off — makes scanning intermittent.
Can an animated QR code change its destination?
No. Frames with different payloads mean the phone acts on whichever frame its shutter caught — effectively a random destination. One animation, one payload. To change destinations over time you need a redirect behind a static payload.
What format should an animated QR code use?
GIF for universal embedding of flat-colour codes, APNG where gradients need full colour depth, MP4 or WebM for signage and stream overlays. Whatever the container, verify by extracting frames and decoding each one.
Does animation make a QR code scan slower?
A compliant animation — every frame decodable — adds little. Any non-decoding frames force the camera to wait for a clean grab, multiplying scan latency. Animating position or scale is worse: it breaks the user's aiming loop entirely.
Try it — free, no signup
Related
- QR code design best practices — seven rules ranked — The seven design rules that decide whether a styled QR code scans, ranked by how often breaking them kills codes, with the number behind each rule.
- Putting a QR code on video — Sizing and placing a QR code burned into video — the 10:1 rule from couch distance, the percent-of-frame maths, and why the code must not move.
- Minimum on-screen duration for a QR code — A primed viewer needs 8–12 seconds to unlock, aim, focus and decode. Show codes for at least 15–20 seconds — or keep them persistent in a corner.
- Scan latency — why some codes scan instantly — The decode pipeline runs in tens of milliseconds, so slow scans lose time upstream. The five causes of sluggish codes, ranked, each with its fix.