What to compare in a QR generator
Start with the destination, not the appearance of the square. The QR code generators offer free QR tools, but a restaurant link, a campaign redirect and a contact card solve different jobs. Decide what should happen after a scan, where future edits should be made and whether the printed code must remain unchanged.
A sound comparison checks five points before an account is chosen. These questions also prevent a business from paying for dynamic behaviour when a stable link would already meet the need.
- Destination: identify whether the final action is opening a URL, opening a managed redirect or saving an embedded contact record.
- Editability: separate changes to the content at a fixed address from changes to the address or redirect target itself.
- Distribution: consider how long the code will remain in print and what must be replaced if its destination changes.
- Measurement: check the analytics history and dynamic-code allowance included in the plan.
- Wallet journey: decide whether recipients should save contact details, open a small website or use both through a supported Wallet flow.
Static URL QR or dynamic QR?
A static URL QR encodes one fixed address. The image can stay on a poster while the page hosted at that address is edited. A PDF can also be replaced at the same address. Only changing the encoded URL itself requires a newly generated static code. This makes static URL codes useful when the destination remains stable but its content needs occasional updates.
A dynamic QR encodes a managed redirect. Its destination can be changed without reprinting, subject to plan limits. This is helpful when campaigns, offers, pages or contact destinations need to be swapped. It also enables dynamic-code analytics within the plan’s history window. The extra control comes from a redirect service, not from changing the printed image.
A common misconception is that a hosted website becomes dynamic merely because its text can be edited. Static URL and dynamic QR codes can both lead to mutable web content. The difference is where the change occurs: at the same destination URL for a static code, or at a destination managed by a redirect for a dynamic code. Neither type guarantees scanning on every device, so test the actual destination and usage conditions before rollout.
Why a static URL QR is not an embedded vCard
An embedded static vCard QR stores contact details in the code itself rather than encoding a web address. The QR acts as the contact handoff. If a phone number, email address, job title or another encoded field changes, the vCard code must be generated again and redistributed; the old printed code continues to carry its original data.
This makes embedded static vCards useful when the contact record is stable and infrequent changes justify replacing printed pieces. It also creates a different maintenance rule from a URL QR: the contact data itself is fixed in the symbol, so an online edit cannot update any copy already in circulation.
For example, a fictional consulting office can use an embedded vCard beside a reception desk when the partner’s direct details rarely change. A seasonal campaign with several possible landing pages is a better fit for a dynamic QR. An always-open company profile can use a static URL if the address stays the same.
QREasy plans and Wallet journeys
QREasy provides digital business cards for Apple Wallet and Google Wallet, a small website builder and free QR tools. In supported Wallet journeys, recipients can review and save contact details or open a website created with QREasy. A contact Wallet card and the first one-page website are free; website-linked Wallet cards require Lite SME or Business.
The QREasy plans make the main capacity differences explicit. All three include unlimited static QR codes; the number of websites, pages per site, dynamic codes and analytics history changes by tier.
- Free: one website with up to one page, one dynamic QR code and unlimited static QR codes. Analytics history is seven days. Contact Wallet cards are included, while website-linked Wallet cards require a paid plan. Price: EUR 0.00 monthly or annually.
- Lite SME: three websites with up to four pages each, 50 dynamic QR codes and unlimited static QR codes. Analytics history is 90 days, and website-linked Wallet cards are included. Price: EUR 2.99 monthly or EUR 28.70 annually.
- Business: 33 websites with up to ten pages each, 357 dynamic QR codes and unlimited static QR codes. Analytics history is 90 days, and website-linked Wallet cards are included. Price: EUR 9.99 monthly or EUR 95.90 annually.
How to choose the right QR solution
Use the decision in this order: define the scan action, identify where updates must happen, select the destination type, match plan capacity and test the real destination. This sequence prevents the most common mismatch—choosing a technical QR type before defining the customer journey.
Three fictional examples show the range. A café can keep a static URL on its counter while replacing a PDF at the same address. A beauty studio can use a dynamic code for a seasonal offer and review the dynamic scan history guide. A trade-show stand can use an embedded vCard when one contact record remains current throughout the event.
Start with the smallest workable setup, print a test, scan it in the conditions where it will be used and document who can change the destination. Revisit the choice when the offer, contact details, number of sites or Wallet purpose changes—not merely because a more complex code type is available.
- If a permanent printed piece should open an editable page or replaceable PDF at the same URL, start with a static URL QR.
- If one printed code must move among campaigns, pages or contacts, consider a dynamic QR and check the applicable plan limits.
- If recipients mainly need a fixed contact record, consider an embedded static vCard and plan how updated codes will be distributed.
- If the handoff is an Apple Wallet or Google Wallet card, decide between contact details and a website linked through the Wallet.
- For a small launch, use Free where its one-site, one-page and one-dynamic-code limits are sufficient; move up only when a needed feature or capacity is missing.
