Wedding QR codes — RSVPs, photos, and registries

Wedding QR codes are one of the few places a QR earns its space on the page without anyone arguing. The print is already happening. The audience already wants to act on it — RSVP, find the venue, send a gift, share a photo. The friction the QR removes is real: aunt Margaret would rather not type bit.ly/sam-and-alex-2026?rsvp=yes&meal=fish into a phone she only uses for calls.

Done right, a wedding QR code on the save-the-date pulls the date into a phone calendar in one tap, an RSVP QR on the invitation opens a form already keyed to the guest, a photo-gallery QR on the menu card collects every drunken candid in one shared album, and a registry QR keeps the gift link working even when the registry tool you picked in February quietly gets acquired in August.

Done wrong, the QR sits on a beautifully printed card no one scans because the contrast is wrong, the URL it points at expires before the honeymoon, or the form behind it asks for a password nobody set up. This post is the version that goes through each wedding QR job — invitation, RSVP, photo gallery, registry, day-of logistics — and the small set of decisions that make each one work on paper that's already at the printer. Teachers and PTAs face an almost identical print-and-scan problem, only with parent communication instead of guest tables — the classroom-handout and parent-portal QR patterns from the education sector is the place to lift their pre-flight habits from.

The four wedding QR jobs#

Most wedding stationery suites end up with four distinct QR codes doing four different jobs. Treating them as interchangeable is the most common mistake. Each one has a different audience, a different conversion goal, and a different failure mode.

The pattern: anything pointing at a third-party service that might change between print and the wedding has to be dynamic. The only code you can sensibly leave static is the calendar event — once the date and venue are locked, the iCalendar payload doesn't change.

RSVPs — the one that actually has to work#

The RSVP QR code is the only wedding QR with hard consequences. Miss a calendar invite and a guest can still ask "what was the date again." Miss an RSVP and you're either short on food or paying for chairs nobody sat in.

The RSVP page behind the QR has to clear five basic bars before anyone even thinks about visuals.

It opens on mobile without pinching. A QR scan happens on a phone. If the form is desktop-first with a tiny RSVP button below a hero image of a beach, half your guests bounce. Test the live page on the cheapest Android you can find before you order print.

The form keys off the URL. A single shared RSVP link asks every guest to type their name, count their plus-ones, and remember which dietary restriction they emailed you last September. Per-guest URLs key off a short slug — yourdomain.com/r/aunt-margaret — and the page pre-fills the household, the seat count, and the meal options the household actually has. That alone moves response rates from "okay" to "people thank you for it."

The submit button is the only call to action. No newsletter signup. No "follow our wedding hashtag." No registry cross-link. Every extra option on the page is a guest deciding to deal with this later, and "later" is the day before the caterer needs the count.

Confirmation is instant and includes the venue. The submit screen has the address, the date, the time, and a link to add the event to a calendar. If the confirmation is "Thanks, we'll be in touch," guests forget the details and email you for them.

The host can edit responses without the guest re-submitting. Aunt Margaret will text you with a meal change. The dashboard needs to let you patch it without her having to find the email and re-scan the card.

If you're running RSVPs on a hosted wedding-website tool, most of this is built-in. If you're rolling your own (a Google Form behind a short URL is a common DIY), three of these bars are on you to clear. The form's per-guest pre-fill is the one DIY setups most often skip. The per-guest slug pattern is the same one larger conferences run through their badge layer — the walkthrough of QR codes across the event arc shows how the same architecture handles registration, day-of check-in, and post-event follow-up when the guest list runs into the hundreds.

The dynamic question — and why static almost always loses#

A static QR encodes its destination URL directly into the printed pattern. Decode the pixels, get the URL. Change the URL and you reprint the cards.

A dynamic QR encodes a short link — lnks.work/k/sam-rsvp — that you control. Scan it and the phone visits the short link, which redirects to whatever URL you point it at right now. Six months later you can swap the destination without touching a single piece of stationery.

For weddings, the case for dynamic is overwhelming because the destinations move:

• The RSVP tool gets acquired. Zola, The Knot, Joy, Minted — all stable today, all moved at least once in the past five years. The forms you build there get migrated or sunsetted on the platform's timeline, not yours.
• The registry gets re-organised. You start with one registry, add a second when the first runs out, switch the linked page to a multi-registry aggregator the week before the wedding.
• The photo gallery URL rotates. Most shared-album tools issue per-event URLs that are valid for a window. The default window is often shorter than your honeymoon.
• The wedding website itself gets a redesign. You move from Squarespace to a Notion page mid-planning. The QR doesn't care, but the URL did.

The static QR can't survive any of this. The dynamic QR survives all of it — you log in, change one field, every printed card resolves to the new destination.

The same architectural argument applies to short links generally: the further down the link infrastructure ownership ladder you push, the less of your stationery suite depends on a vendor staying in business through November. Pointing a custom short-link domain you control at the redirect server is the version of this that survives a platform exit without anyone seeing a 404.

Photo galleries — the QR that works during the event#

Photo-gallery QR codes are the only wedding QR that gets scanned in real time during the event. The job is to put one URL on every menu card, every table number, every restroom door so guests upload their photos to the same shared album.

Three things make this work and one thing kills it.

Make it. Show it. Scan it. Same QR on every printed surface guests will see at the event — menu, table number, photo-booth backdrop, even a small card by the bar. Redundancy isn't tacky; it's how the QR gets used at all. Guests scan when they're inside the moment, not because they're hunting for the right card.

The destination needs zero login. "Sign in to Google Photos to contribute" loses everyone over 40. The page behind the QR has to accept uploads from any phone's photo picker without an account. Several wedding-album tools handle this; some don't. Test it on a phone you've never logged into the service from.

Auto-tag by table. Worth it if you can. A different QR per table — /photos/table-3 — lets the album sort by table after the event. Guests don't notice. Six months later you'll find every photo from table 12 in one place when you compile the book.

The thing that kills it: limits. A free tier of a photo-share tool that caps at 50 photos or 1 GB will fill up by 9pm. Pick the tier that survives a wedding before you print. The QR will still scan when the limit hits — it just lands on an upload page that won't accept the file. Guests don't try a second time.

The interactive: what kind of wedding QR do you need?#

Most couples want one of four setups. Tap through the toggles to see which combination fits, and what to put behind each code before sending the file to the printer.

The picker is opinionated on purpose. Two of the four jobs (RSVP, registry) demand dynamic short links you can repoint, one (photo gallery) demands a destination that survives a Saturday night, and only one (calendar event) is safe to encode statically.

Print constraints that quietly break wedding QRs#

Wedding stationery has constraints that day-to-day QR codes do not. The paper is fancier. The print run is small enough that nobody catches the bad code until it's at every place setting. The expectation is "this looks beautiful," which fights with "this scans every time."

The five constraints worth pre-flighting:

Module size at print resolution. A wedding invitation often runs the QR at 1.5-2cm. At 1.5cm with a version-3 QR code (29x29 modules), each module is about 0.5mm wide. Some letterpress and foil techniques can't hold a 0.5mm dot reliably — the ink bleeds, the dot smears, the decoder loses the edge. Bump to a 2cm code or simplify the data (shorter URL = smaller version = bigger modules).

Quiet zone. Every QR needs a four-module margin of plain background around it. The decoder uses that border to find the code. Wedding stationers love putting decorative borders, ribbons, or "RSVP" labels right against the code. The four-module margin is non-negotiable — measure it after the designer hands back the artwork.

Foil and metallic ink. Gold or silver foil over QR modules looks great on the invitation and fails ~30% of scans because the metallic surface reflects flash and varies wildly with viewing angle. Foil borders around a black QR are fine. Foil modules are a coin flip.

Letterpress depth. Deeply pressed letterpress creates micro-shadows on the modules. In good light, fine. In dim reception lighting, the shadows become spurious "dark modules" and the decoder mis-reads. If the rest of the suite is letterpress, run the QR at a higher error correction level (Q or H) to absorb the noise.

Coated paper at angle. Glossy coatings reflect overhead lighting and the camera flash. Hold the card flat and the QR is half-glare. Same issue with the worst of the lamination finishes. Either go matte for any card with a QR or test the scan at 30 degrees off the vertical, which is how guests will actually hold it.

The same logic applies to outdoor and large-format QR printing — print conditions decide more than the design tool does, and the wedding equivalent is "the venue's reception lighting is darker than your living room test."

Save-the-dates and calendar QR codes#

The save-the-date is the only piece of wedding stationery where the obvious QR job is "add this date to the recipient's calendar." Skipping the calendar QR and going straight to a wedding-website link is a missed opportunity — every recipient who does not actively click "add to calendar" on a webpage will forget the date within a month.

A calendar event QR code encodes an iCalendar VEVENT directly into the pattern. Scan it, the phone prompts "Add event to Calendar?", tap once, done. iOS recognises the format natively. Android does too, with one wrinkle: some Android camera apps offer "open in browser" first and "add to calendar" second, which trips a fraction of users who tap the wrong option.

The VEVENT payload for a wedding looks like this:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//yourdomain//Wedding//EN
BEGIN:VEVENT
UID:sam-alex-wedding-2026-09-12@yourdomain.com
DTSTART:20260912T160000Z
DTEND:20260912T230000Z
SUMMARY:Sam & Alex's Wedding
LOCATION:The Old Mill\, 12 River Lane\, Cotswolds
DESCRIPTION:Ceremony at 4pm\, reception following.
URL:https://yourdomain.com/wedding
END:VEVENT
END:VCALENDAR

Two things to know. The LOCATION field accepts commas — but commas have to be escaped as \, because the iCalendar format uses commas as a list separator inside multi-value fields. Forgetting the escape is the most common parse failure. And the DTSTART timestamp is in UTC (the trailing Z); guests' phones convert to local time automatically. If your venue is in a destination with daylight-saving weirdness, double-check the converted time on a phone set to a different timezone before printing.

Static is the right call here. The date and venue do not change. Encode the VEVENT directly into the QR and skip the redirect server entirely — your save-the-date does not need to survive a vendor outage three years later.

Photo galleries — the QR that earns its space at the reception#

Half the value of a photo-gallery QR shows up in the year after the wedding, when the professional photos have been delivered and you realise the best shot of the night was the one your second cousin took on his phone at 11pm. The other half shows up when guests at separate tables stop sending you "did you see this?" group texts and just upload everything to one place.

The setup that works:

• One short URL per event, printed on every table card, the menu, the photo booth backdrop, and a small card behind the bar.
• The destination is a shared album that accepts uploads without anyone signing in. Most major photo tools support guest uploads on a paid tier; the free tier is the one that fails on the night.
• A separate QR per table (/photos/table-3, /photos/table-7) if you want auto-grouping by seating chart. Most couples skip this and one big album works fine.
• A signed-in admin page for you, so the morning after, you can pull every photo into your own backup before the shared-album tool's free preservation window expires.

The dynamic angle matters less here than for RSVPs but still earns its keep — if the photo-share tool you picked changes its URL structure between contract and event, you re-point the short link without anyone noticing.

Registries — and why "QR straight to one store" is a trap#

The registry QR is the one most couples wish they had set up differently in retrospect. The default move — QR points straight to the Crate & Barrel registry, or straight to the Amazon registry, or straight to the Zola registry — locks you into that store for the life of the printed cards. Move the registry, add a second store, decide to take honeymoon cash instead, and the QR is wrong.

The setup that survives is one layer of indirection: the QR points at your wedding website's registry page, which lists every place you're registered. Add or remove a store on the page; the QR keeps working.

If you don't have a wedding website, a single short link on a domain you control (the custom short-link domain flow takes about 15 minutes end-to-end) does the same job. The link goes to a page you can edit any time. Aggregator services like Zola and The Knot have built-in versions of this and they work, with the caveat that the aggregator can change its URL structure or sunset its registry feature on its own timeline.

The cost asymmetry is the part most couples miss: the cost of pointing the registry QR at a single store, then deciding to add a second store, is "reprint a stack of cards or accept that half your guests can't find the new store." The cost of pointing at an aggregator page from day one is "build a page with one link on it." The asymmetry is the whole argument.

The same indirection thinking shows up in the broader own-your-link-infrastructure pattern and the case for branded short links over generic shorteners. The wedding-specific version is just "your registry strategy changes more than your printed paper does."

Day-of QR codes — the easy wins#

Beyond the four main jobs, a handful of day-of QR codes earn their space at the reception:

• Seating chart QR. One QR at the entrance points at the master seating chart. Guests scan, find their table, do not crowd the printed board. Worth it for events over 80 guests.
• Menu / ingredients QR. Especially useful for plated dinners with allergen concerns. The card has the meal name; the QR opens a page with the full ingredient list. Lower-friction than asking the server.
• vCard QR for the couple. A dynamic vCard QR code on the back of the program lets guests save your new shared contact info — useful if you're changing names, moving, or just want one card that gives long-distance relatives the new household details.
• Speaker bios / ceremony program. A QR on the printed program opens the full version (longer bios, full readings, the playlist). Saves paper and lets guests refer back later.

None of these are mandatory. They each pull weight in specific situations. The seating-chart QR alone saves about 30 minutes of crowd-around-the-board at the start of the reception, which is the kind of small win that pays back the 20 minutes it takes to set up.

What we built around this#

Linked.Codes runs the redirect layer that any of these QR codes can sit on top of. Bring a domain (or use a free subdomain), generate per-guest slugs in the dashboard, point the QR designer at the slug, and your printed code resolves to whatever you want it to — today, six months from now, or after a registry change. The whole wedding suite can live under one domain, with the dashboard showing scan counts per code so you can see whether the registry QR is actually getting used.

The dynamic angle is the same one we cover in the post on why every QR type should be dynamic by default — wedding QR codes are the most concrete case for the rule, because the gap between printing and the event is long, the gap between the event and the last gift is longer, and every third-party tool in the chain has its own timeline.

For most couples, free is enough — one domain, a handful of slugs, low monthly volume. The lifetime tier becomes interesting if you're a wedding planner running this for multiple weddings a year, in which case the white-label QR setup starts to make sense.

What to do this week#

If you're at the print-the-invitations stage:

1. Lock the RSVP tool. Generate per-guest slugs before sending the file to the printer.
2. Decide on dynamic vs static for each QR. Default to dynamic for anything pointing at a third-party tool.
3. Order a five-card test print. Scan every QR on the test print with three different phones. Note the failures.
4. Fix the failures. Re-print test. Confirm. Then run the full order.

If you're at the save-the-date stage: lock the venue, generate the calendar VEVENT, encode it as a static QR, ship the cards. Worry about the RSVP infrastructure in three months when you actually need it.

The work that makes wedding QR codes scan reliably is not the design tool. It is the 20-minute pre-flight on a test print with three phones, and the architectural decision to put a redirect server you control between your printed pixels and the third-party tools whose timelines you do not.

Related reading#

• Calendar event QR codes — get an event into a phone fast — the full RFC 5545 walkthrough for the save-the-date QR
• Dynamic vCard QR codes — why most generators skip them — for the "save our new household contact" QR
• Why you should own your link infrastructure — the layered argument for why dynamic short links matter
• QR codes for nonprofits — donations, volunteers, awareness — adjacent print-led, event-attached use cases
• Round QR codes — what actually makes them work — for couples who want the QR to match the stationery aesthetic
• QR codes — platform docs — the QR designer on Linked.Codes