A QR code on a screen is the one placement where the code might be the wrong tool entirely, and almost nothing written about "QR codes for virtual events" says so. A QR code exists to do one job: move a person from a surface they cannot click to a phone they are already holding. Someone watching a webinar is sitting at a keyboard. Whether a code on a screen earns its place depends entirely on where the viewer's hands are — and that single question decides everything else on this page.

First decide whether the viewer can click

Work through where the audience actually is, because the answer is different for each and the wrong one wastes the slide.

A room, with the slide on a projector or a big screen. The audience has phones and cannot click the screen. This is the QR code's natural home, and everything below about size and time applies with full force.
A television, a lobby screen, digital signage. Same situation: hands free, screen far away, nothing to click. The code is right.
A recording watched later on a TV. Same again — and this is why a code in a video is worth doing even when the live audience did not need it.
A webinar or video call, watched on a laptop. The viewer can click. A link in the chat is faster than any code, and a short, readable URL on the slide is second. Put the code up as well, for the people watching on a second monitor or with the meeting on a tablet, but do not make it the only route.
A stream or a recording watched on a phone. The code is useless to them. A phone cannot scan its own screen — how to scan a QR code explains the screenshot workaround, but nobody watching a video is going to do it. Those viewers need a link in the description, a pinned comment or the chat.

For a hybrid event the honest setup is both: the code serves the room, the chat link serves the remote half, and the recording gets a persistent code for the people who watch it on a television next month. Same destination, delivered three ways — and if you make them three separate dynamic codes or short links, the scan counts will tell you which audience actually used which, which is the only way to find out.

Size: the distance rule, and the distance is bigger than you think

A code reads from up to about ten times its own width. On a business card that is a comfortable arm's length. On a screen the arithmetic runs the other way: take the distance from the screen to the furthest viewer, divide by ten, and that is how wide the code has to be on the screen.

Do it for a real room. A meeting room where the back row is six metres from the display needs a code about sixty centimetres across — on a two-metre-wide projection, that is nearly a third of the slide. A lecture hall makes it worse. A code sitting in the bottom corner of a slide at the size it was on the handout is a decoration; nobody past the second row is scanning it.

So on a slide, the code is not a corner element. When the code is the point of the slide, it is the slide: a white panel, the code filling most of it, one line of text saying where it goes, and nothing else. On a webinar the viewer is close but the code renders small — a corner overlay on a thirteen-inch laptop might be three or four centimetres across, which is borderline at desk distance. Go full-frame for the moment that matters and back to the corner afterwards.

The other lever is the same one that fixes most scanning problems: encode fewer characters. A short address means fewer modules, and fewer modules means each one is larger at the same size on screen, which is what survives distance, compression and a mediocre camera. A dynamic short link scans better on a screen than a long tracked URL before anyone has touched the design. QR code design that still scans goes through the rest — and a heavily styled code with a logo in the middle is exactly the wrong choice for something read from six metres.

Time: leave it up far longer than feels comfortable

A printed code can be studied at leisure. A code on a screen is gone when the slide changes, and the sequence it has to survive is longer than presenters assume: notice the code, decide to bother, find the phone, unlock it, open the camera, aim, wait for the banner, read it, tap. For an attentive person that is fifteen to twenty seconds. For a room, where half the audience notices when the other half raises a phone, it is longer.

Say it out loud. "There is a code on screen — I will leave it up." Half the job of the code is being noticed, and the presenter is the only thing on stage that can direct attention.
In a talk, put the code on the closing slide and leave it there through the questions. The Q&A is the longest a single slide is ever on screen.
In a video or a stream, a persistent corner overlay for the whole segment beats a five-second full-screen card. People pause a recording; they do not scrub back for a card they half-noticed.
Never put a code on a slide that transitions. A code that fades, slides or zooms is unreadable for the whole animation and confusing afterwards.

The frame: where it sits and what covers it

Streams and recordings are shown inside somebody else's interface, and that interface draws over the picture. Captions sit along the bottom. Progress bars, timestamps and volume controls appear on hover along the bottom edge. A channel watermark lives in one corner, usually the bottom right. End cards and "up next" panels cover the corners in the last seconds. Live chat, on some layouts, eats the right-hand side.

The upshot: bottom right is the worst place on the frame, and the bottom fifth of the picture is unreliable everywhere. Top left or top right, away from the very edge, is usually safe; mid-left on a wide frame is good for a persistent overlay. Whichever you choose, give the code its own plain panel — a white rectangle with real margin inside it — rather than dropping it straight onto the video. The blank border around a code is part of the code, and a busy moving background behind it is the same failure as printing over the margin.

On a video call there is one more trap: do not trust your own preview. Some apps mirror the self-view, some do not, and a virtual background gets smeared around a moving person. A code in a virtual background is a gimmick that mostly fails at the edges of your shoulders. Share it as a slide instead, and check what other people see from a second device before the meeting, not during it.

Compression, dark mode and shimmer

Video is compressed, and compression discards fine detail first — which is exactly where a QR code stores its information. A code that is crisp on your source file can arrive at a viewer on a poor connection as a grey smudge with corners. Two things fix it: bigger modules (a shorter address, a bigger code) and higher contrast. And one test: watch your own stream on its lowest quality setting, on a different device, and scan it from where a viewer would sit. If it reads at 360p it will read anywhere.

Dark decks are fashionable and QR codes hate them. A light pattern on a dark slide is an inverted code, which is out of spec, and a lot of phone cameras will simply not see it. Keep the code black on a white panel even on a dark theme — the panel is doing a job, not breaking the design.

If a phone camera pointed at a screen shows a shimmering pattern over the code, that is the camera's grid fighting the screen's grid. It is usually harmless; if it stops the scan, moving back a few centimetres or making the code larger on screen almost always clears it.

What it should open

The same rules as any code, with two things sharpened. First, the destination must work on a phone held in one hand by someone who is also trying to listen to you: light, no login, the thing they came for at the top. Where should a QR code point is the fuller argument. For a talk that is the slides, the reading list, a feedback form or a signup. For a stream it is the specific thing you just mentioned, not your homepage.

Second — and this is the strongest case for a dynamic code anywhere — a recording cannot be edited after it is published, and a deck gets presented for years. A static code bakes the address into the pattern permanently; when the resources move, every recording and every copy of the deck points at nothing. A dynamic code encodes a short address you can re-point later, so the video from two conferences ago still lands somewhere useful. The trade-off, that you are depending on the redirect continuing to exist, is set out in static vs dynamic QR codes; for anything recorded, accept it.

And say what it opens, right next to it: "Scan for the slides", not "Scan me". On a screen the line beside the code has to work from the back row too, so it is one short line in large type. What to put next to a QR code is about that line.

Virtual events specifically — the honest version

For a fully online event, be clear-eyed. The live audience can click, so the primary handoff is a link — in the chat, in the platform's resources panel, in the follow-up email. The QR code earns its place for the recording, for viewers with the stream on one screen and a phone in hand, and for any moment the audience is not at a keyboard. It does not earn its place in a virtual background, on a title card for four seconds, or as a substitute for putting the link where people can click it.

Where it comes into its own is everything that is not purely virtual: the hybrid room, the watch party, the in-person breakout, the printed programme, the badge, the banner by the door. Those are the surfaces where hands are free and screens are far, and that is the situation the code was built for. QR codes at events and trade shows covers that floor — including the network, which is the thing that breaks first.

A test that takes two minutes

Put the slide on the actual screen in the actual room. Walk to the back. Scan it with an ordinary phone camera — not a scanner app, which is more forgiving than the audience's cameras. For a stream, open your own broadcast on a television or a second laptop at its lowest quality, sit where a viewer sits, and scan from there. If either fails, the code is too small or too short-lived, and both are fixed in the deck before anyone is watching.

The short version

Ask where the viewer's hands are. Room, TV, recording: use a code. Laptop: the link in the chat comes first; the code is a backup. Phone: the code is useless, give them a link.
Size it for the back row — distance to the furthest viewer, divided by ten. On a slide that usually means the code is the slide.
Encode a short address so the modules are big enough to survive distance and compression.
Leave it up — through the questions, or as a persistent overlay for the whole segment. Never on a slide that animates.
Stay out of the bottom fifth of the frame, and away from the bottom-right corner, on anything streamed or recorded.
Black code, white panel, even on a dark deck. Test on the stream's lowest quality.
Make it dynamic for anything recorded or any deck you will present again.
Test from the back of the real room, or from the couch on your own stream.