QR Code Generator Guide: How to Create QR Codes Online
A QR code is won or lost long before anyone points a phone at it. What decides the outcome is not the click that draws the image but the parameters behind it. The same URL produced at error correction level L needs a 33×33 grid; at level H it needs 41×41 — the printed size is identical, yet every module shrinks by a quarter. Add three tracking parameters to that URL and the version jumps from 6 to 9. Codes that will not scan, codes that fail on a glass door, codes ruined by a logo dropped in the centre: almost all of these are decided at generation time.
This guide covers the four things a generator interface never explains: which settings fit which scenario, what you actually trade when you raise error correction, how to troubleshoot a printed code in the right order, and how static and dynamic codes differ in cost, editability and risk. Every module count below was measured with the same encoding logic our QR code generator uses, so you can reproduce it.
1. The Scenario Picks the Parameters
Only three things are adjustable: content, size and error correction level. The best combination differs sharply by scenario, and settings that suit a business card are usually wrong for an outdoor poster.
| Scenario | Typical content | Suggested level | Where the real constraint is |
|---|---|---|---|
| Business cards, booth material | Contact details | H | Room for a centre logo; the more fields, the denser the code |
| WiFi sharing | Network name and password | M or Q | One screen displays it, another phone photographs it — brightness and moiré matter |
| Indoor posters, shelf labels | Short link | Q | Viewed within about a metre, so modules must stay printable |
| Outdoor advertising, light boxes | Short link | Q or H | Long viewing distance sets the size; the code must survive dirt and scuffs |
| Packaging, curved labels | Short link | H | Curvature and creases distort the geometry, so more redundancy is needed |
| Payments, event check-in | Editable short link | M or Q | The destination may change or needs counting — a static code cannot do it |
Two rules cover most of it: if the code can be scuffed, covered or wrapped around a curve, raise the level; if it only ever appears on a clean screen, do not pay for redundancy you cannot use. The last row is a different problem, covered in section 5.
2. Error Correction: 30% Is a Limit, Not a Budget
QR codes carry redundancy through Reed-Solomon error correction. The four levels correspond to recoverable codeword ratios of roughly 7% (L), 15% (M), 25% (Q) and 30% (H). Those figures are easy to misread as permission to cover a third of the code. They are the outer boundary of the correction capability, and real deployments need headroom: once damage approaches the limit, a slightly tilted scan or dim light is enough to break decoding.
The redundancy is not free. For the same content, a higher level means more check codewords, which forces the code into a larger version. Version is the size class of a QR code: version 1 is a 21×21 grid, every later version adds 4 modules per side, and version 40 reaches 177×177.
| Version | Grid | When you land here |
|---|---|---|
| Version 1 | 21×21 (441 modules) | Very short content: a short link or a plain number |
| Version 4 | 33×33 (1,089 modules) | A URL of fifty-odd characters at level L or M |
| Version 6 | 41×41 (1,681 modules) | The same URL at level H, or a slightly longer payload |
| Version 10 | 57×57 (3,249 modules) | A long link with several query parameters |
| Version 20 | 97×97 (9,409 modules) | Paragraph-length text or a full contact record |
| Version 40 | 177×177 (31,329 modules) | The largest size the specification allows, rarely needed in practice |
The conversion is worth memorising: modules per side = 17 + 4 × version. Version scales linearly with the side length, but the module count grows with the square, so each step up consumes noticeably more area than it looks like it should.
The encoding mode matters too. The same characters pack tighter in numeric or alphanumeric mode than in byte mode, and Chinese text encoded as UTF-8 costs more bytes still. That is why shortening the URL is usually more effective than fiddling with any other setting.
3. Worked Example: One 53-Character URL at Four Levels
Take the address of one of our guides, https://www.calc-tools.top/blog/en/qr-generator-guide — 53 characters — and generate it at each of the four correction levels. Measured results:
| Level | Recoverable | Measured version | Grid | Module width at 3 cm |
|---|---|---|---|---|
| L | about 7% | Version 4 | 33×33 (1,089) | about 0.91 mm |
| M | about 15% | Version 4 | 33×33 (1,089) | about 0.91 mm |
| Q | about 25% | Version 5 | 37×37 (1,369) | about 0.81 mm |
| H | about 30% | Version 6 | 41×41 (1,681) | about 0.73 mm |
Moving from L to H raises the module count from 1,089 to 1,681, an increase of 54%. The printed size has not changed, so each module falls from 0.91 mm to 0.73 mm. Press registration error, ink spread on paper and the autofocus precision of a phone camera all have to hold up at that scale. Higher correction is only half a win: fault tolerance goes up while readability goes down.
Content length bites harder than the level. Append three tracking parameters and the payload grows from 53 to 87 characters, which pushes level H from version 6 to version 9 — a 53×53 grid, 2,809 modules, 67% more than before. Shrink instead: swap the 53-character address for a 27-character short link and level L drops from version 4 to version 2, a 25×25 grid of 625 modules, 43% fewer modules than the original.
Put the two results together and the order of operations becomes obvious: shrink the content first, then argue about the level. Shortening content lowers the version, and a lower version improves readability and fault tolerance at the same time. Raising the level alone trades one for the other.
How large should the code be? The common rule of thumb is that a code can be read from about ten times its side length, though published guidance ranges from five to ten times; taking the smaller factor is safer. At ten times, being readable from 3 metres requires a side of at least 30 cm, where a 41×41 grid gives modules of roughly 7.3 mm — comfortable. Force the same level H code into 1.5 cm and each module is about 0.37 mm, at which point print quality decides whether it scans at all.
When you place a code into a poster, scale it as vector artwork or by whole-number multiples, so resampling does not blur module edges into grey fringes; see image resize and crop and the image resizer for the mechanics. If the link contains spaces or non-ASCII text, percent-encode it first — otherwise different scanners may resolve different addresses. The URL encoder is the quick way to check.
4. Six Reasons a Printed Code Will Not Scan
When a code fails, the first instinct is to blame the correction level. In practice the level is almost never the cause. Work through this list in order.
| Symptom | What is actually wrong | Fix |
|---|---|---|
| It never focuses, nothing happens | Insufficient contrast: grey modules on a pale background, or light modules on dark | Dark modules on a light background, as much contrast as possible — avoid same-hue pairings |
| Works up close, fails from a distance | Too small, or modules too dense | Size from the ten-times rule, and shorten the content to lower the version first |
| Edges never read; it only works when perfectly square-on | Quiet zone trimmed away — the code was pushed against artwork or a colour block | Leave at least 4 modules of clear space on all four sides, and keep that space light |
| Some phones read it, others do not react at all | Inverted colours: light modules on a dark background | Return to the standard colour scheme; some decoders simply reject inversion |
| Fails on cylinders, pouches and fabric | Geometric distortion from curvature, creases or steep angles | Reduce the code area, raise the correction level, or switch to a flat label |
| On-screen codes that another phone cannot photograph | Low brightness, screen glare, or moiré from digital zoom | Maximum screen brightness, avoid direct light, and never use digital zoom |
Check the quiet zone and contrast first — those are the two things layout work eats most often. Then check whether the size matches the viewing distance. Question the correction level last, because raising it makes the grid denser and can make the problem worse.
5. Static vs Dynamic Codes: When You Have to Pay
What a generator hands you by default is a static code: the content is encoded into the artwork itself, and the image is the entire payload. Its properties are rigid in both directions — you cannot change the content, only reprint; but it depends on no server and stays valid as long as the image is readable.
A dynamic code looks the same but resolves to a short link, with the real destination held on the provider's server. That extra hop buys three things: an editable destination, scan analytics, and routing rules by time or region.
| Dimension | Static code | Dynamic code |
|---|---|---|
| Where the data lives | In the artwork | Only a short link in the artwork; the target sits on a server |
| Changing the destination | New artwork and a reprint | Edit in a dashboard; printed codes keep working |
| Scan analytics | Not possible | Counts by day and by region |
| Failure risk | Valid as long as the image is readable | Breaks if the service stops, the account lapses or the domain expires |
| Cost structure | One-off production and print cost | Usually an annual subscription — factor it into long campaigns |
| Privacy | The scanner talks only to the destination server | Every scan passes through the provider and is logged |
The test is simple: if the material is already printed while the destination may still change, use a dynamic code; if artwork and destination are frozen together, or the code must last for years, use a static one. Business cards, packaging and book appendices fall into the second group, where a static code removes any dependence on a third party staying in business. Campaign pages, menus and advertising slots fall into the first, where the reprint cost a dynamic code avoids usually dwarfs the subscription.
6. Offline Security: Swapped Payment Codes and Misleading Destinations
A QR code carries no provenance. The person scanning only sees where they end up, which leaves room for two kinds of attack.
Sticker swapping. Payment codes, parking payment slips and shop posters are all physical stickers. Overlaying a merchant's code with your own, or replacing a payment slip code with a transfer code, is cheap and direct. Merchants should keep the code in sight, inspect it regularly and enable audio payment alerts; payers should verify the recipient name before confirming, which beats chasing the money afterwards.
Misleading destinations. A static code can encode any address, including a look-alike login page. Short links make this harder to spot, because the only thing a human sees is a short domain that reveals nothing about the final destination. Any page that asks you to log in, pay or enter identity details deserves two extra seconds of domain checking.
Public WiFi codes and event check-in codes deserve the same caution. The former may point at an impostor hotspot; the latter may lead to a third-party page requesting permissions. If a scan immediately asks for a login, a phone number or an app install, ask whether that step is actually necessary.
7. Four Counterintuitive Mistakes
Mistake 1: setting error correction to H for safety. A higher level means a higher version and a denser grid, so at a fixed print size each module gets smaller. On material printed at ordinary quality and read from a distance, H can scan worse than M. Choose by scenario: M or Q on clean screens, H when the code may be covered, scuffed or wrapped around a curve.
Mistake 2: generating a tiny code and enlarging it inside the layout. A QR code is a binary graphic; scaling up adds no information, it only interpolates modules into bigger blocks. Poor resampling blurs module edges into grey, and once the grey sits near the decoding threshold, errors begin. Enlarge as vector, or regenerate at the target size.
Mistake 3: assuming QR codes expire. Static codes do not — the image is the data, and it keeps working as long as the image can be read. What expires is a dynamic code: the artwork is unchanged, but the short link behind it dies when the service stops, the account lapses or the domain expires. Almost every claim about QR expiration is really about a dynamic code's service term.
Mistake 4: making the centre logo as large as it looks good. The logo covers modules outright, so the covered area must stay inside the correction limit and must not obscure the three corner finder patterns. Level H's 30% is the boundary of the error correction capability, not a usable area budget. Any code with a logo should be tested on several phone models rather than estimated by area.
8. Frequently Asked Questions
Will a logo in the middle break the code?
Not necessarily, but the covered area must stay inside the correction capability and must not touch the three corner finder patterns. The usual approach is to generate at level H, keep the logo well below the 30% correction limit, and scan-test the result on several phone models. Once coverage approaches the limit, a slight angle or dim light is enough to fail.
Why will my printed code not scan?
Usually not the correction level. The frequent causes are a trimmed quiet zone, weak contrast and a code that is simply too small. Leave at least 4 modules of clear, light space on all four sides, keep dark modules on a light background, and size the code from the ten-times viewing rule. Only after those three are ruled out should you suspect content that is long enough to make the grid too dense.
Do QR codes expire?
Static codes do not. The content is encoded in the artwork, so it works as long as the image can be read correctly. Dynamic codes do expire: the artwork points at a short link, and the redirect breaks when the service stops, the account lapses or the domain expires.
Why is someone else's code for the same URL sparser than mine?
Three things usually explain it: a higher correction level, a longer payload, or a different encoding mode. Adding a few query parameters can push the version up by one to three steps. To get a sparser code, shorten the link to a few dozen characters first, and lower the correction level second.
Can a payment QR code be swapped?
Yes. A static payment code is a sticker or a small stand, and covering it costs almost nothing. Merchants should keep it in sight, check it regularly and enable payment alerts; payers should verify the recipient name before confirming, which is far more effective than trying to recover the money afterwards.
9. Four Practical Rules
- Fix the content before the level. Shorten the link, drop tracking parameters you will not read, then choose a level for the environment. Reversing the order means spending readability to compensate for a wasteful payload.
- Print a proof and test it. Produce the code at final size and scan it several times on different phone brands and in different lighting. Codes with logos, curved labels and outdoor placements deserve this step most; it prevents almost all wasted print runs.
- Budget space for the quiet zone. At least 4 modules of clear space on every side, no dark artwork touching it, and no trim line running through it. Treat the quiet zone as part of the code, not as available whitespace.
- Do not post-process a bitmap code. Scale vector artwork, or regenerate at the target size in the QR code generator. Dropping a bitmap code into a layout and scaling it repeatedly leaves grey fringes that fail silently.
A QR code is a small system that ties parameters, printing and placement together. Anything skipped at generation time comes back the moment someone tries to scan it. When you need a code right away, generate it with the online QR code generator using the parameter table above, and download it at the size you actually need.