How a QR Card actually works
A card that collects data. Five minutes of reading covers four things: what it is, how it differs from a QR code, why it can still change after it's printed, and everything you need to know before you print.
① Definition
What is a QR Card?
A card that collects data. It's built from three parts, each with its own job — the face, the code, and the page after the scan. Miss any one of them and all you have is paper with a QR code stuck on it.
The face
Gets someone to understand within 3 seconds and decide whether to scan: the headline says what it's about, the CTA says what scanning does, the status badge says whether there's still time.
The code
The one way in. Always dark code on white — that's the scannability red line, and no color scheme or material gets to break it.
After the scan
A mobile page sharing the card's visual DNA that completes one clear action — sign up, check in, give feedback. Status and data flow back to the creator in real time.
It is not a "dressed-up QR code". Making a code pretty does not turn it into a card.
② The fundamental difference
Code vs Card
A code is a pointer: it points somewhere else, gets discarded after the scan, and is nothing on its own. A card is an object: it has boundaries, state, and exactly one action.
Just a code
Scans and jumps away — nothing happened.
No content, no state, no outcome.
A card
Understood, scanned, signed up — spots and status flow back in real time.
The printed paper never changed; the card never stopped changing.
| QR code (Code) | QR card (Card) | |
|---|---|---|
| What it is | A pointer: points somewhere else | An object: has its own job |
| What people see | A black-and-white blob — you only find out once you scan | A card you read in 3 seconds: what it is, what to do, and whether you're too late |
| After the scan | Jumps away, no trace left | One action completed, data flowing back live |
| State | Static forever | Open → full → waitlist → closed, updated live |
| Changing content | Requires a new code and a reprint | Links and status change anytime; the code never reprints |
③ Still changing after print
Dynamic Cards
The face lives on paper; the state lives in the cloud. A card's full lifecycle: open → full (auto-switches to waitlist) → waitlisting → closed (the deadline closes it automatically) → cloned for the next round. No reprinting the paper, no regenerating the code.
{{ {open:'Still taking spots: first come, first served', full:'All 30 spots gone: closed automatically', waitlist:'Oversubscribed: the interest stays on the waitlist'}[c.content.status] }}
Notifies you only at the moments that matter
Full, waitlist, deadline — each card pings the creator only at those three moments and stays quiet the rest of the time. Data flows back in real time; no exports to compile, no bloated dashboards.
The next round clones from this card
Recurring events don't start from scratch: clone the card, change only the date and the spot count, and the QR code stays the same — anything already printed keeps working.
④ Under the hood
How it's made
Every card is a card.json: four layers keep "what it does" and "what it looks like" cleanly apart — so the same card can swap into any color scheme or material without losing a single word of content.
content
What it does
Headline, CTA, fields, spot count, deadline; for link cards, the URL and page title.
layout
How the slots are arranged
classic centered / split columns / minimal — the layout decides what shows up where.
style
What it looks like
24 color schemes × 12 materials × 3 card sizes × 3 corner radii — mix freely.
widgets
Widgets & parameters
Code size, code color and dot shape, badge tone, CTA style — every widget tuned independently.
- Type guards URL cards automatically disable spot progress and status badges — widgets that don't fit are blocked at the spec layer, not by someone remembering to do it.
- Fluid type Every face sizes its type with container queries (cqw) — one implementation flows from business card to poster without reflowing a word.
- One renderer Any page that outputs the same DOM contract can rebuild the full card with the same card.css — the home workbench, the 18 brand generator pages, and the industry template previews stay identical forever.
- The scannability red line The code area is always dark-on-white; before every export, three checks run automatically — error-correction level, contrast, and size gradient.
⑤ Print guide
Print & Scan Guide
A QR card ends up printed in the physical world. Six rules decide what scans and what doesn't.
Dark code on a white zone
This is the iron law. On dark faces the code sits in a white rounded container — the generator already handles it, so it's not a layer you check at export.
Minimum physical size
The code needs at least 0.8 in (2 cm) on a side to scan at arm's length; add about 0.4 in (1 cm) for every extra 3 ft (1 m) of viewing distance — scale posters by distance.
Don't crop the quiet zone
The blank margin around the code (at least 4 modules wide) is part of the scan — keep design elements from crowding into it at layout time.
Matte first
Glossy coated stock and glossy lamination throw glare that whites out the scan; matte paper and matte film are the safest bets.
Test before the print run
Print one proof before the full run and actually scan it with at least two phones — ideally including an older model.
Where it hangs
On glass or metal surfaces, watch ambient glare and the scanning angle; for outdoor materials, choose a weatherproof laminate.
Read the theory — now make one
No sign-up needed; one sentence generates your first card — and every step of the generation is the theory above, in physical form.