Logo image
Drop PNG/JPEG/SVG here or browse to replace.
| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
QR codes are two-dimensional matrix symbols that turn a small square of dark and light modules into usable text. A scan can open a link, join a Wi-Fi network, save a contact, start a message, or add an event because the decoded text matches formats that phones already know how to hand off to the right app.
A camera does not see a destination directly. It sees geometry, reconstructs text, and then lets the operating system decide whether that text is a URL, a phone action, a mail action, a contact card, or calendar data. That is why a QR code with the same visual size can behave very differently depending on what is encoded inside it.
Scan reliability depends on more than the artwork looking crisp. Capacity, error correction, module size, quiet zone, foreground-to-background contrast, and any center obstruction all work together. A symbol that looks fine on a bright screen can become unreliable once long structured text, low-contrast colors, glossy stock, or a large logo reduce the spare margin the scanner needed.
The real-world use cases are straightforward: menus, posters, guest-network cards, packaging, business cards, badges, and slides. The limit is just as important. A QR code only carries text. It cannot fix a broken link, confirm a password is still current, or make an unfamiliar destination trustworthy, so the final check is always a real scan of the finished symbol.
QR Code versions run from 1 to 40. Version 1 is 21 by 21 modules, and each higher version adds 4 modules to both width and height. More payload bytes or a higher error-correction level push the symbol toward a larger version. If the canvas size stays fixed, each module becomes smaller, which is why dense codes are harder to scan from a distance or after rough printing.
Most action-oriented QR codes are still text at their core. A web link is stored as the exact link text. Email and phone actions use URI schemes such as mailto: and tel:. Contact and event payloads use line-based text records, which is convenient for scanners but more verbose. That extra structure is often invisible to the person filling the form, yet it still counts toward capacity.
| Payload family | Encoded text shape | Practical note |
|---|---|---|
| Link or plain text | Exact text as entered | Usually the shortest and most forgiving choice when one scan only needs to reach a page or show a short message. |
| Wi-Fi access | WIFI:T:<mode>;S:<ssid>;P:<password>;H:true;; |
Convenient for guest networks, but special characters must be escaped and any password change makes the code stale. |
| Email or phone | mailto: or tel: URI |
These usually prepare an action in the device app. They do not send a message or place a call by themselves. |
| SMS | Common SMSTO:number:message convention |
Many scanners understand it, but it is less formalized than mailto: or tel:, so device testing matters more. |
| Contact card | BEGIN:VCARD ... END:VCARD |
Convenient for names, job titles, numbers, email, and a site link, but every optional line adds bytes quickly. |
| Calendar event | BEGIN:VCALENDAR ... END:VCALENDAR |
Useful for a single event summary, place, time, and note. UTC timestamps keep the record consistent across systems. |
Error correction levels L, M, Q, and H trade payload room for recovery headroom. Official QR guidance describes them as roughly 7%, 15%, 25%, and 30% restoration capability for total codewords. That extra protection helps when a print gets dirty or a center logo covers part of the data area, but it also increases the symbol size needed for the same content.
The blank border matters just as much. QR guidance calls for a quiet zone that is four modules wide on every side. Contrast matters too. The warning threshold used here is 4.5:1, which is a practical readability floor borrowed from accessibility guidance rather than a formal QR pass-fail rule. The aim is conservative design, not a claim that a single ratio can predict every scanner on every surface.
The Scan Readiness Index shown later is a local heuristic, not a QR standard. It blends payload headroom, color contrast, quiet zone, logo coverage, and the chosen error-correction level into one risk signal so you can see which tradeoff is doing the damage.
| Symbol | What it measures | How it behaves here |
|---|---|---|
H |
Capacity headroom | Starts high when UTF-8 byte count stays well below the selected capacity and falls sharply once usage moves near or past the limit. |
C |
Color contrast | Uses foreground and background relative luminance, with the best score reserved for very strong dark-on-light separation. |
Q |
Quiet zone margin | Reaches full value at 4 modules of clear border and drops when the surrounding margin is reduced. |
L |
Logo safety | Steps down as the square center image grows beyond 10%, 15%, 20%, 25%, and 30% of symbol area. |
E |
ECC resilience | Maps the chosen level to a fixed resilience value, with H highest and L lowest. |
A short https:// link is often the better first draft than a packed contact card or event block. If the real goal is to land someone on a page, let that page carry the extra detail instead of forcing it into the symbol. Shorter payloads usually scan faster, stay on lower versions, and leave more room for branding later.
The built-in templates cover eight common one-scan actions: website URL, plain text, Wi-Fi access, email compose, phone call, SMS message, contact card, and calendar event. Contact and event modes are the easiest places to overpack the symbol because even a small set of visible fields expands into structured text behind the scenes.
Branding is where most avoidable failures begin. Rounded dots, gradients, frame styles, and a center logo are easiest to judge after the plain version already scans on another phone. If Warning count is not zero, clear the warning or accept the tradeoff consciously before printing, sharing, or embedding the code in a design.
https:// link for web destinations, include country code for phone numbers, and keep contact or event records lean at first.The preview is only the artwork. The more meaningful read is the combination of Scan Readiness Index, Warnings, and the size clues in Payload Blueprint. A symbol can look sharp while still being too dense, too low-contrast, or too heavily branded for reliable scanning.
| Visible cue | Best first reading | What to do next |
|---|---|---|
| Robust at 85 or higher | The design still has useful margin for ordinary scanning conditions. | Test the final size on real devices, then export the format you need. |
| Balanced from 70 to 84 | The code will often work, but one tradeoff is already eating into safety. | Use the radar to see whether density, contrast, logo size, or quiet zone is the main weakness. |
| Risky from 50 to 69 | The symbol may scan only in clean lighting and at comfortable distances. | Simplify the payload or styling before assuming a larger canvas will save it. |
| Fragile below 50 | The design is too close to failure for routine use. | Rework the payload, colors, margin, or logo before distribution. |
| Capacity used near the top band | The code is approaching the selected level's byte budget. | Shorten optional fields or use a simpler payload form before increasing artwork size. |
| Contrast below 4.5:1 or quiet zone below 4 modules | The problem is visual separation, not raw payload size. | Restore a lighter background, darker foreground, or a wider clear border. |
Version estimate and quiet zone in pixels become especially important on paper. A symbol that works at 360 pixels on screen can fail once it is printed too small, because every module and every margin shrink together. Treat a strong score as a screening result, not a guarantee, and always scan the final output under the same lighting and surface conditions your users will face.
A short link such as https://example.com/menu usually stays compact. With ECC M, a white background, a dark foreground, no logo, and a 4-module quiet zone, the symbol often lands in the Robust range with few or no warnings. That is the ideal baseline because the scan action is obvious and the payload is easy to keep small.
A guest-network card needs an SSID, security mode, password, and sometimes a hidden-network flag. That is still manageable, but adding a 24% logo while staying on ECC M usually drops logo safety and raises a warning. The better fix is to reduce logo coverage or move to ECC H, then scan the printed card from typical arm's length instead of judging only from the preview.
A calendar code that includes a summary, location, start time, end time, and a long note becomes dense faster than it looks. If the end time is earlier than the start time, the warning list catches that logic error even though the symbol still renders. If the description is long enough to push the version up, trimming the note is usually more effective than enlarging the artwork.
QR capacity moves in steps, not in a smooth line. A few extra vCard lines, event notes, or encoded subject text can push the payload into the next version bucket, which makes the module grid larger and the same artwork denser.
No. They normally hand a tel: or mailto: action to the device app so the user can review it. The QR code prepares the action, but the user still confirms it.
Not to the same degree. mailto: and tel: have formal URI specifications, while SMSTO: is a widely used convention. It often works well, but it deserves extra device testing if SMS is the main purpose of the code.
No. Higher error correction helps, but it does not restore data that is completely covered by an oversized image or lost to weak contrast and missing quiet zone. Logo size still needs restraint.
No separate backend is used for this tool. Payload assembly, scoring, charting, and logo file reading all happen in the browser after the page loads.