Dynamic vs static QR codes: the difference, and which one to print
Every QR code generator offers both, and the difference is not cosmetic. One is a photograph of an address. The other is a forwarding service with a picture on the front. Pick the wrong one and you either reprint a menu, or lose the menu to somebody else's pricing page.
A static QR code encodes the destination address in the image itself. It never expires, needs no account, and can never be changed. A dynamic QR code encodes a short redirect link; the redirect can be pointed anywhere, any time, and can count scans, but the code only works while somebody keeps that redirect running. Static for things that will not change; dynamic for things that might, and on your own domain if the print run is expensive.
What a static QR code is
Type https://cafe.example/menu into a generator and it converts those 26 characters into a grid of black and white squares, with enough redundancy that a phone can read them from a slightly bad photograph. That is all a static QR code is: an address, drawn as a picture. The phone decodes the picture, gets the address back, and opens it.
Three consequences follow. It works forever, because nothing sits between the phone and your page. It costs nothing, because there is no server to run. And it cannot be edited, because the address is literally what is printed. If the menu moves, the code still says where it used to be.
Static codes can carry more than a URL. A WiFi code encodes the network name and password so a guest phone joins in one tap; a contact card (vCard) encodes a name, phone and email. The free generator here makes all of these, in your browser, with nothing sent anywhere.
What a dynamic QR code is
A dynamic QR code does not contain your address. It contains a short link on a redirect service, something like stqr.click/k2Xm9pQ. When a phone scans it, it opens that short link; the service looks up what k2Xm9pQ currently points to, and sends the phone on with an HTTP redirect. The phone lands on your page a fraction of a second later and the visitor never notices the hop.
Because the destination is stored on the server rather than in the squares, you can change it any time. The printed code stays the same; the redirect changes. That one property gives you everything else dynamic codes are sold on:
- Edit after printing. Fix a wrong link on 5,000 menus without reprinting any of them.
- Scan analytics. The redirect server sees every scan, so it can count them, by day, by country, by device type.
- Shorter codes. A short link is 15 to 20 characters. A long URL with tracking parameters is 100 or more. Fewer characters means fewer squares, which means the code scans at a smaller printed size. Minimum QR code size for print has the numbers.
- One code, many campaigns. Point it at the spring menu, then the summer one, then a survey.
Side by side
| Static | Dynamic | |
|---|---|---|
| What the squares encode | Your address | A short redirect link |
| Editable after printing | No | Yes |
| Can expire | Never | Yes, when the redirect stops |
| Scan counts | No | Yes |
| Needs an account | No | Yes |
| Ongoing cost | None | Usually a subscription |
| Printed size for a long URL | Larger | Smaller (short link) |
| Works if the vendor disappears | Yes | Only if the redirect is on your own domain |
| Can carry WiFi or a contact card | Yes | Only via a web page |
When static is the right choice
Static is the default, and most people who ask this question should use it. It is the right choice when the destination is stable and you do not need to count scans: a link to your home page on a business card, a WiFi code on the wall of a café, a contact card on a name badge, a link to a product manual on the box, a one-off event poster. It costs nothing, it needs no account, and it cannot be taken away from you.
The test is simple: if this link changed, would reprinting be a disaster? If reprinting is a five-minute job, static.
When dynamic is worth paying for
Dynamic is worth it when the print run is expensive or permanent and the destination is not. A restaurant that prints 5,000 laminated menus and changes the online menu twice a year. Packaging that will sit in warehouses for eighteen months. A sign etched into a shop front. A real-estate board that will be reused on the next listing. Anything where you would otherwise be tempted to print a URL with tracking parameters, because the short link keeps the code small and the analytics come free.
It is also the only way to get scan counts, if you need to know whether the code on the bus shelter is doing anything.
The catch with dynamic codes
The redirect server has to keep running for as long as the code is in circulation, and for a printed code that can be years. Somebody pays for that, which is why dynamic codes come with a subscription, a scan cap, or a trial that ends. That part is reasonable.
The part to think hard about is whose domain is in the code. With almost every dynamic QR service, the short link is on the vendor's domain: qrco.de, bit.ly, flowcode.com. That means the printed code is only as durable as your relationship with that vendor. If the price rises at renewal and you decline, the codes stop. If the free tier is withdrawn, the codes stop. If the vendor is acquired and the product sunset, the codes stop. And because the domain is theirs, there is nothing to move: your only options are pay, or reprint.
The pattern that generates most complaints in this category is exactly that: sign up free, print, get told at renewal that the plan now costs three times as much, and discover that leaving means reprinting everything. Do QR codes expire? covers the specific vendors.
The third option: dynamic, on your own domain
The way out is to put the redirect on a hostname you own. The code encodes qr.yourbusiness.com/k2Xm9pQ instead of a vendor's short link. Your DNS points that hostname at the vendor's redirect service, which does the same job as before: looks up the code, sends the scanner on, counts the scan.
The difference shows up on the day you want to leave. Because the hostname is yours, you export your code list, point the DNS record at a different service (or a two-line redirect script of your own), and every printed code keeps working. The vendor never held the off switch. This is how SteadQR is built, and it is the reason it exists: dynamic codes should be as durable as static ones, and only your own domain makes that true.
How to tell which one you have
Scan the code with your phone's camera and read the address in the banner before tapping it. Your own address means static. A short link on another company's domain means dynamic, on their terms. A short link on a subdomain of your own site means dynamic, on yours.
Can you convert one into the other?
Not a printed one. A static code's pattern is derived from the address, so there is no way to make an existing print "become" dynamic; the phone will always read the address that was encoded. You can generate a new dynamic code that points at the same page and use it on the next print run, but the codes already out there stay static forever. The reverse is also true: a dynamic code cannot be made static after the fact, because it encodes the short link, not your page.
This is the strongest argument for deciding before printing. Choose static and you can never add editing later. Choose dynamic on a vendor's domain and you can never remove the dependency later. Choose dynamic on your own domain and both doors stay open.
Need a static code? The free generator makes links, WiFi and contact cards in your browser, PNG and SVG, no account. Need to change it after printing? SteadQR dynamic codes, on your own domain, are in build: join the waitlist.
Open the free generatorAll guides · Free QR code generator · Dynamic codes waitlist