Thirty-two years after Hara Masahiro and his small team at Denso Wave shipped the first specification for a "quick response" matrix barcode designed to track automotive parts on a Toyota assembly line,[1] the QR code has become the world's most-scanned visual symbol. It moves payments in São Paulo, opens menus in Brooklyn, joins Wi-Fi networks in Tokyo, and authenticates passports in airports across forty countries. India alone processed roughly 16.99 billion UPI transactions in March 2026, the overwhelming majority initiated by a phone camera pointed at a printed QR.[2]
It is also the most successful phishing vector of the post-pandemic era. The FBI's Internet Crime Complaint Center has issued repeated public advisories about QR-code fraud since 2022;[3] the U.S. Federal Trade Commission's December 2023 consumer alert led directly to a 2024 increase in "quishing" reports;[4] and the U.S. Cybersecurity and Infrastructure Security Agency now treats QR-borne URLs as untrusted-by-default in its mobile-threat guidance.[5]
Picking a generator and using it well sits at the intersection of those two facts. This guide walks through what the underlying ISO/IEC 18004 standard actually specifies, which payload formats every modern phone understands without a third-party app, how error correction works and which level to pick, what the EMVCo merchant-payments specification adds on top, how the UPI and Pix rails actually scale, what quishing looks like in the wild, and an eight-item checklist for any QR you generate and publish in 2026.
▣Open the CalcLeap QR generator
Browser-only, no tracking, no signup. Wi-Fi, vCard, URL, and plain-text payloads. Download as PNG.
The state of the QR code in 2026
The QR code is the closest thing the internet has to a universal physical hyperlink. The 2020 pandemic broke the previous decade of slow Western adoption and pushed scanning into restaurants, parking meters, public-transit stations, vaccine cards, and church bulletins. The 2026 inheritance of that shift is a global installed base that is best understood in payment volumes.
India. The Unified Payments Interface, an RBI-backed real-time payment rail launched in 2016, handled 16.99 billion transactions worth ₹24.77 lakh crore (approximately US $295 billion) in a single month — March 2026 alone — almost all initiated by scanning a QR.[2] NPCI's UPI 123Pay extends the same flow to feature phones via IVR, and UPI Lite handles small-value offline payments without a PIN. UPI is now the world's largest real-time payments system by transaction count.
Brazil. Pix, launched in November 2020 by the Banco Central do Brasil, processed roughly 64 billion transactions in 2025, with QR scans accounting for the majority of merchant payments and the dominant share of peer-to-peer transfers.[6] Pix is now ubiquitous in São Paulo street markets, taxi receipts, and small-business invoices. The Central Bank's Pix QR specification is published openly and free to implement.
China. WeChat Pay and Alipay between them handle the bulk of urban Chinese retail payments through QR codes — typically in "consumer-presented mode," in which the customer's app shows a one-time QR to the merchant scanner rather than the other direction. The pre-COVID transaction volumes (north of 240 billion mobile-payment transactions in 2019, per People's Bank of China data) have only grown.
The United States and the European Union. Both lag the leaders, but the rails are converging. The U.S. FedNow service, live since July 2023, supports request-for-payment flows that can be wrapped in a QR. PayPal, Venmo, Cash App, and Block all support merchant QR acceptance. In the EU, the SEPA QR standard published by the European Payments Council as EPC069-12 lets any euro-denominated invoice fit in a single QR symbol.[7] The EMVCo Merchant-Presented Mode specification provides the technical lingua franca if and when global processors converge.[8]
The composite picture: in 2026, a QR code is no longer a curiosity. It is a load-bearing piece of global financial infrastructure, and the underlying specification has been quietly stable for three decades — which is why your phone scans codes printed in 1996 just fine.
What ISO/IEC 18004 actually specifies
The international standard for the QR code symbology is ISO/IEC 18004, originally adopted in 2000 and most recently revised in 2024.[9] The standard defines four pillars: the geometric structure, the four data-encoding modes, the four error-correction levels, and forty version sizes.
Every QR symbol contains three large square finder patterns in three corners (the squares-within-squares that let a scanner locate the symbol at any rotation), an array of smaller alignment patterns, two timing patterns of alternating modules along the edges of the data area, format information surrounding the finders, and the data payload itself encoded as a snake-path through the remaining modules.
The four data-encoding modes are picked automatically by any decent encoder to minimize symbol size:
| Mode | Character set | Bits per character | Best for |
|---|---|---|---|
| Numeric | 0–9 only | 3.33 bits | Phone numbers, account IDs, integer payment amounts |
| Alphanumeric | 0–9, A–Z, space, $ % * + - . / : | 5.5 bits | Uppercase URLs, ticket codes, short alphanumeric IDs |
| Byte (8-bit) | Latin-1 / UTF-8 bytes | 8 bits | Mixed-case URLs, vCards, Wi-Fi credentials, any human-readable text |
| Kanji | Shift JIS double-byte | 13 bits | Japanese text encoded efficiently |
A URL in uppercase alphanumeric uses 35 percent fewer bits than the same URL in mixed-case byte mode. This is why some payment-protocol QRs are intentionally all uppercase.
Every QR symbol declares a version from 1 to 40 that determines its grid size. Version 1 is 21×21 modules; each successive version adds 4 modules per side, so version 40 is 177×177. Larger versions hold more data but require a higher-resolution scan. Encoders pick the smallest version that fits the payload at the chosen error-correction level.
Error correction: the four levels and how to choose
The single piece of QR-code design that mattered most to its real-world adoption was its use of Reed-Solomon error correction, the same algorithm used in CD audio, DVB-T broadcast television, and the Voyager probes' deep-space telemetry.[9] Reed-Solomon lets the scanner reconstruct the full message even when a portion of the symbol is dirty, smudged, torn, or covered with a logo. The QR specification exposes four selectable error-correction levels:
| Level | Recoverable damage | Symbol penalty | Use when… |
|---|---|---|---|
| L | ~7% | Smallest symbol | Clean digital display; max payload density |
| M (default) | ~15% | Small | Indoor print, posters, on-screen sharing |
| Q | ~25% | Larger | Print with small logo overlay; outdoor exposure |
| H | ~30% | Largest | Logo embedded in code; heavy wear; small physical size |
A subtle point that trips up most "design your own QR with a logo" tools: the higher the error correction, the more modules the symbol contains, which means each module is smaller at a fixed printed size. Past a certain point, raising the level to hide a bigger logo actually makes the code harder to scan from a distance, not easier. The right move is to bump the error correction to H, then make the entire printed code larger — not to keep the same size and rely on more redundancy.
The error-correction rule of thumb
Logo, print, or potential wear → Level H. Indoor poster or screen-share → Level M. Maximum payload in a clean digital context → Level L. There is no scenario in which you should pick a level above what you need: extra redundancy makes the code denser, not safer.
The payload formats every modern phone understands
The QR code itself is just bytes. What turns those bytes into a useful action — opening a URL, joining a Wi-Fi network, adding a contact — is a set of de-facto payload conventions that every major phone camera supports without a third-party app. Picking the right one is the difference between "the user has to install something" and "it just works."
URL
The simplest and most common payload. Any string beginning with a recognized scheme — https:, http:, mailto:, tel:, sms:, geo:, or a registered app scheme — is interpreted as an actionable link by iOS Camera, the Android Google Lens, and every general-purpose QR scanner. Use HTTPS. Keep the URL under 80 characters when possible; use a short, custom URL on a domain you control rather than a public URL shortener.
Wi-Fi credential
The WIFI: format originated in the open-source ZXing library and is now natively recognized by iOS 17+ and Android 10+. Encode it into a QR, paste it on the fridge, and any guest can join your network without ever typing a password.
WIFI:T:WPA;S:GuestNetwork;P:Tw0-Coconut-Lake-River-42;;
// Fields:
T: WPA, WPA2, WPA3, WEP, or nopass
S: SSID (escape ; , : \ with backslash)
P: Password (omit for open networks)
H: true if hidden SSID (optional)
Contact (vCard or MeCard)
Two competing formats. The MeCard format, invented by NTT DoCoMo for early Japanese phones, is shorter; the vCard format, standardized in RFC 6350, is universally recognized by every modern phone and most desktop address books.[10] Use vCard 3.0 or 4.0 for any business-card QR you intend to last.
BEGIN:VCARD
VERSION:3.0
FN:Sasha Lin
ORG:Acme Co.
TEL;TYPE=CELL:+14155550139
EMAIL:sasha@example.com
URL:https://example.com
END:VCARD
EMVCo Merchant-Presented Mode (payments)
The global standard for printed merchant QR-code payments is the EMVCo Merchant-Presented Mode (MPM) specification, version 1.1.[8] Every parent payment scheme — UPI in India, Pix in Brazil, PromptPay in Thailand, PayNow in Singapore, EMVCo internationally — derives its merchant QR from this format. The payload is a tag-length-value sequence beginning with a fixed payload-format indicator and ending with a CRC checksum:
00 02 01 // Payload format indicator
01 02 12 // Point of init = dynamic
26 36 ... // Merchant account info
52 04 5812 // Merchant Category Code (restaurant)
53 03 840 // Currency = USD (ISO 4217)
54 06 12.50 // Transaction amount
58 02 US // Country code
59 09 ACME CAFE // Merchant name
60 09 SAN FRAN // Merchant city
63 04 A8B3 // CRC-16-CCITT
For European invoices, the parallel format is the EPC069-12 SEPA QR ("Quick Response Code: Guidelines to enable data capture for the initiation of a SEPA Credit Transfer"), which encodes IBAN, BIC, beneficiary name, amount, and remittance information.[7] Most European banking apps recognize it natively.
Calendar event, geo-location, plain text
The BEGIN:VEVENT iCalendar payload pre-fills a calendar entry. The geo:37.7749,-122.4194 URI opens the system map app at coordinates. A QR containing arbitrary plain text simply shows the text to the user. All three are universally recognized.
What "best" really means in a free QR generator
Search "free QR code generator" and you will find a thousand pages, of which perhaps a dozen are good. The standard markers of a poor or actively hostile tool:
- The generator inserts its own short URL. Many "free" generators encode
https://qr.cheapvendor.com/abcdefinstead of your actual URL, then redirect at scan time. This breaks privacy, breaks longevity (when the vendor folds, your QR dies), and lets the vendor sell your scan analytics. A real generator encodes your exact destination directly. - It requires an account. You should never have to log in to encode a string into 21×21 to 177×177 modules. Generation is a pure function; an account is a tracking opportunity.
- It runs server-side without a clear privacy disclosure. Wi-Fi passwords, vCards, and EMVCo payment payloads are sensitive. The generator should run entirely in your browser so the payload never traverses the network.
- It exposes only "dynamic" codes. Dynamic codes are static codes pointing at a trackable redirect on the vendor's domain. If "static" mode is not visible, the vendor is selling tracking by default.
- It hides error-correction level and version. Real generators let you pick L/M/Q/H explicitly. Hiding the choice means the tool is making it for you — usually wrong, often for filesize or display reasons unrelated to your scanning conditions.
The CalcLeap generator at /qr-code-generator.html encodes entirely client-side, requires no account, exposes all four error-correction levels, supports URL / Wi-Fi / vCard / plain-text payloads, and downloads as a standard PNG with no tracking. Open developer tools and watch the network tab — zero outbound requests fire when you click Generate.
⚙Try the CalcLeap QR generator
Static codes only. PNG output. Free, no signup. Works offline once the page loads.
Static vs dynamic QR codes — when each makes sense
A static QR encodes the destination payload directly. The bytes inside the symbol are the URL, the Wi-Fi credential, or the vCard. Scanning the code performs the action with zero intermediate hop. Nothing about a static QR can be tracked, updated, or revoked — it lives forever.
A dynamic QR encodes a short URL on the generating vendor's domain. When scanned, the vendor's server logs the scan, optionally checks geo or device data, then redirects to whatever destination you have configured in the vendor's dashboard. Dynamic codes let you change the destination after printing and give you per-scan analytics; in exchange, you depend on the vendor permanently and reveal scan metadata to them.
| Property | Static | Dynamic |
|---|---|---|
| Destination editable after print | No | Yes (via vendor dashboard) |
| Survives vendor going out of business | Yes | No — every printed code goes dead |
| Scan analytics (timestamp, IP, geo, device) | None | Vendor sees everything |
| Subscription cost | $0 forever | $5–50/mo per code typically |
| Privacy for the scanner | Best | Worst (vendor intermediates) |
| Best for | Restaurant menus, business cards, Wi-Fi, payments | Marketing campaigns that need analytics |
The single decision that matters: if the QR points at a stable URL that you control (your own domain), use static. You can change the destination of example.com/menu server-side any time without reprinting; you do not need a dynamic-QR vendor in the middle. The dynamic-QR pitch ("update the destination later!") only makes sense if you cannot also control the destination URL — which is rarely the actual constraint.
Quishing: the 2026 phishing wave
"Quishing" — phishing delivered through a QR code — has been the fastest-growing vector in the post-pandemic phishing landscape. The FBI's January 2022 public-service announcement warned that cybercriminals were tampering with QR codes "to redirect victims to malicious sites that steal login and financial information."[3] The FTC's December 2023 consumer alert noted scam patterns including QR codes on parking-meter stickers, in delivery-notification emails, and on phony shipment notices.[4] CISA's mobile phishing guidance now lists "URL within a QR code" as a category alongside SMS smishing and email phishing.[5]
The attack pattern is consistent across reported cases:
- The decoy. A poster, parking sign, restaurant receipt, "package delivery failed" email, or vehicle-charging-station label, with an attached QR code purporting to lead to payment, login, or tracking.
- The redirect. The QR encodes a short URL on a recently registered domain that visually resembles the legitimate brand (
chase-billing.support,parkmeter-pay.net). - The login or payment page. A pixel-perfect replica of the real site that captures credentials, card numbers, or installs a malicious "tracking app."
- The cash-out. Captured credentials are either used directly for account takeover, sold on credential-stuffing marketplaces, or — for the more sophisticated rings — bundled with stealer-log access and resold.
Three properties of QR phishing make it more dangerous than the email or SMS variant. First, mobile contexts (a parking meter, a restaurant table) make the user time-pressured and less likely to scrutinize a URL. Second, the URL is hidden inside the symbol until the moment of preview, so traditional URL-filtering at the email or DNS layer never sees it. Third, the legitimate use of QR codes for payment in India, Brazil, China, and increasingly the U.S. has trained users to trust the format itself.
The one defense that works
Every modern phone camera previews the destination URL before opening it. Read the preview every time. If the URL does not match the brand on the sign — exactly — do not tap. Note that "exactly" matters: chase.com is real, chase-billing.support is not, and the attacker counts on the user reading the first six characters and dismissing the rest.
For QR codes you generate yourself and post in public — restaurant tabletop, parking pay-station, signage — the defenses on the publisher side: print the destination URL in human-readable text next to the QR ("scan, or visit chase.com/parking-pay"), use a custom short domain you control rather than a public shortener, watch for sticker tampering on physical signs, and avoid encoding sensitive directly-actionable payloads (Wi-Fi credentials, payment QRs) on assets that strangers can physically alter.
Best practices for QR codes you publish
Generating a QR is the easy step; publishing one that scans reliably for the next decade requires a handful of choices that most "free QR generator" pages quietly get wrong.
Sizing for the scan distance
A reliable rule of thumb: the printed QR should be at least 1/10 the distance from which it will be scanned. A code expected to be scanned from one meter away should be at least 10 cm on a side. A code on a billboard meant to be scanned from 20 m away needs to be at least two meters on a side. Smaller printed codes need higher-resolution scanners and clean optics — they fail at the long tail of older phones.
Quiet zone
Every QR code requires a clear margin — the "quiet zone" — of at least four modules on all sides, free of any markings.[9] Crowding the symbol with text or other graphics is the single most common cause of "the camera won't scan it" complaints in the wild.
Contrast and color
Dark-on-light, with a minimum contrast ratio of about 4:1. Avoid inverting (light modules on dark background) — many older or industrial scanners are tuned for dark-on-light only and will refuse the inverted form. Avoid colored modules entirely for any code intended to scan from print; they reduce contrast under variable lighting and offer no benefit. If you must add color, restrict it to the quiet zone and the surrounding label.
Logos and customization
You can embed a small logo at the center of the code, but pair it with error correction level H (30 percent), and keep the logo to no more than 25 percent of the total symbol area. The "fancy" rounded-modules and gradient-fill effects offered by some vendors look attractive on screen and fail spectacularly when printed at small sizes; stick to square modules for any production use.
Testing
Every QR you publish should be scanned with at least three devices before the run goes to print: a current iPhone (iOS Camera), a current Android (Google Lens), and one mid-range Android more than two years old (the long tail that breaks first). Test in both indoor fluorescent and direct sunlight. Test on a damp print proof — wet ink slightly distorts modules and is a common reason a code fails at first delivery.
Your QR-code action checklist
- Pick the right payload format for the action. URL for "go here,"
WIFI:for guest networks, vCard for contact cards, EMVCo MPM for payments. Plain text only as a last resort. - Use a static code unless you have a specific reason for dynamic. A static QR pointing at a URL on your own domain gives you the editability benefit of dynamic without the third-party dependence.
- Pick error-correction level H when there will be a logo, outdoor exposure, or small print size. M is fine for indoor posters and screens. L only for clean digital contexts where you need every bit of payload.
- Print the destination URL alongside the code in human-readable text. Lets users sanity-check the destination before scanning, and gives a fallback when a scan fails.
- Test on at least three real devices before any printed run. Current iPhone, current Android, mid-range two-year-old Android. Test under both fluorescent and direct sunlight.
- Preserve a four-module quiet zone. Do not crowd the code with surrounding text or graphics. The margin is part of the code.
- For payment QRs, use the EMVCo MPM specification or the regional derivative (UPI, Pix, SEPA QR). Avoid proprietary or processor-specific formats unless the audience is captive to that processor.
- When scanning, always preview the URL before tapping. Every modern phone camera shows it. If the destination does not match the brand on the sign, walk away.
Related CalcLeap tools
QR codes are one piece of a broader digital-utility kit. Tools on CalcLeap that pair naturally with this guide:
- QR Code Generator — the standalone tool. Static codes for URL, Wi-Fi, vCard, plain text. Client-side. PNG output. No tracking.
- Password Generator — for the Wi-Fi password you are about to encode in your guest-network QR. Use the longest random string your router accepts.
- Hash Generator — useful for verifying the integrity of a file referenced by URL inside a QR.
- Tip Calculator — relevant whenever a restaurant's QR code menu does not break out tax and gratuity clearly.
- Business Mileage Calculator — for small businesses generating mileage-tracking QR codes for fleet vehicles.
- HELOC Payment Calculator — included for completeness; payment QRs increasingly accompany printed loan statements.
Frequently asked questions
What makes a QR code generator the "best" in 2026?
Three properties matter more than feature counts. First, the generator must encode entirely client-side — your payload (Wi-Fi password, contact card, payment string) should never touch a server. Second, it must let you choose the error-correction level (L/M/Q/H) explicitly so the code keeps scanning even when partially damaged or covered by a logo. Third, it must produce a stable, openly specified output that follows ISO/IEC 18004 — not a proprietary "smart" format that requires a redirect through the vendor's domain. Generators that hide a tracking redirect inside an otherwise normal-looking QR code are the dominant scam vector in 2026.
Are "dynamic" QR codes worth paying for?
Sometimes, but usually no. A dynamic QR code is just a static QR code that encodes a short tracker URL on the vendor's domain; the vendor then redirects the user wherever they want at scan time. The benefit is you can update the destination after printing. The cost is permanent dependence on a third party — when the vendor's subscription lapses or the vendor shuts down, every printed QR you own goes dead. For anything that will be printed once and used briefly (a restaurant menu, a one-off event), a static QR encoded directly with the destination URL is cheaper, faster, more private, and outlives any vendor.
What is quishing and how big is the problem in 2026?
Quishing is phishing delivered through a QR code — typically a poster, email attachment, parking-meter sticker, or in-person flyer that points to a fake login page or a malware download. The FBI Internet Crime Complaint Center has flagged QR-code fraud as a persistent and growing category since 2022;[3] CISA's mobile-threat guidance treats QR-borne URLs as untrusted by default.[5] The defense is simple: every modern phone camera now shows the destination URL before opening it — read it, and if it does not match the brand on the sign, do not tap.
Which error-correction level should I pick?
Pick H (30 percent) if the code will be printed at small physical size, embedded with a logo, or exposed to outdoor wear. Pick Q (25 percent) for printed marketing material with a small overlay. Pick M (15 percent, the default) for on-screen display, posters, or anything indoor. Pick L (7 percent) only when you need to cram the maximum amount of data into a single symbol — for example, a long URL or a payment payload — and the display surface is clean and well-lit. Higher levels make the code denser at a given payload size, which paradoxically can make small printed codes harder to scan.
Can a QR code encode my Wi-Fi password?
Yes. Modern phones recognize a payload of the form WIFI:T:WPA;S:NetworkName;P:Password;; and automatically offer to join the network when scanned with the system camera on iOS 17+ and Android 10+. The format is published by the Zxing project and supported by Apple and Google's camera apps without any third-party app. For a guest network at home or a small office, this is the single highest-leverage QR you can print — generate one, laminate it, stick it on the fridge, never type a 24-character password again.
What is the maximum data a QR code can hold?
The largest QR version (40) at the lowest error-correction (L) encodes up to 7,089 numeric characters, 4,296 alphanumeric characters, or 2,953 bytes.[9] In practice, you almost never want to push that limit — a Version 40 code is a 177×177 grid of modules that requires a high-resolution scanner and is brittle in print. For real-world use, keep payloads under ~300 characters; if you exceed that, link to a hosted page rather than encoding the data inline.
Are QR-code payments (UPI, Pix, WeChat Pay) coming to the United States?
Slowly. The U.S. payment rail FedNow launched July 2023 and supports request-for-payment flows that can be encoded as QR codes, and major U.S. processors (PayPal, Venmo, Cash App, Block) all support QR-based merchant acceptance. But the U.S. lacks a single national QR-payment standard analogous to India's UPI or Brazil's Pix; what exists is a fragmented set of processor-specific QR codes. The global EMVCo Merchant-Presented Mode specification provides the technical baseline if and when U.S. processors converge.[8]
Is the CalcLeap QR generator free, and does it track me?
Free and untracked. The generator at /qr-code-generator.html runs entirely in your browser — your payload is never transmitted, logged, or stored. You can verify by opening developer tools, switching to the network tab, and clicking Generate; you will see zero outbound requests. Output is a standard ISO/IEC 18004 PNG that any QR scanner — including the iOS Camera app, the Android Google Lens, and every barcode reader at every Western Union counter — can read without a redirect through our domain.
Methodology & sources
This guide synthesizes the international QR-code symbology standard (ISO/IEC 18004:2024), the EMVCo Merchant-Presented Mode payment-QR specification (v1.1), regional payment-system data from the NPCI for UPI and the Banco Central do Brasil for Pix, payload-format references from the IETF / RFC series and the open-source ZXing project, and consumer-protection advisories from the U.S. FBI Internet Crime Complaint Center, the FTC, and CISA. Throughput, transaction-volume, and adoption figures cite the most recent month or year published by the originating authority as of May 2026. Error-correction percentages are the nominal recoverable-damage figures published in the ISO/IEC 18004 standard; real-world recoverable damage depends on the specific module pattern and the location of the corrupted area within the symbol. The companion generator at /qr-code-generator.html encodes payloads entirely client-side using a vanilla-JavaScript implementation; no data is transmitted, logged, or stored.
Sources cited:
- Denso Wave Inc., "History of QR Code" — the original specification was developed in 1994 by a team led by Hara Masahiro at Denso Wave (then a subsidiary of Toyota's Denso Corporation) to track automotive parts. Denso Wave holds the QR Code patent and licenses it royalty-free for use under the ISO/IEC 18004 standard. qrcode.com/en/history
- National Payments Corporation of India (NPCI), "UPI Product Statistics." UPI processed 16.99 billion transactions worth ₹24.77 lakh crore in March 2026; the largest real-time payments system in the world by transaction count. npci.org.in/upi/product-statistics
- Federal Bureau of Investigation, Internet Crime Complaint Center (IC3), Public Service Announcement Alert Number I-011822-PSA, "Cybercriminals Tampering with QR Codes to Steal Victim Funds," January 18, 2022, and subsequent IC3 advisories through 2025. ic3.gov/Media/Y2022/PSA220118
- U.S. Federal Trade Commission, Consumer Alert, "Scammers hide harmful links in QR codes to steal your information," December 6, 2023. consumer.ftc.gov/consumer-alerts/2023/12
- Cybersecurity and Infrastructure Security Agency (CISA), "Phishing Guidance: Stopping the Attack Cycle at Phase One" and related mobile-threat guidance. QR-borne URLs are listed alongside SMS smishing and email phishing as untrusted-by-default. cisa.gov/phishing-guidance
- Banco Central do Brasil (BCB), "Estatísticas do Pix." Pix processed roughly 64 billion transactions in 2025; merchant QR codes account for the majority of in-person Pix payments. bcb.gov.br/estabilidadefinanceira/estatisticaspix
- European Payments Council, EPC069-12 "Quick Response Code: Guidelines to enable data capture for the initiation of a SEPA Credit Transfer," current version. The single-symbol SEPA QR format covers IBAN, BIC, beneficiary, amount, and remittance information for euro-denominated credit transfers. europeanpaymentscouncil.eu/EPC069-12
- EMVCo LLC, "EMV QR Code Specification for Payment Systems: Merchant-Presented Mode (MPM)" v1.1. The global tag-length-value format underlying UPI, Pix, PromptPay, PayNow, and most non-Chinese merchant QR payments. emvco.com/specifications (QR Code)
- International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 18004:2024 "Information technology — Automatic identification and data capture techniques — QR Code bar code symbology specification" (current edition, supersedes 2015 revision). Defines the four data-encoding modes, four error-correction levels (L 7% / M 15% / Q 25% / H 30%), and 40 version sizes. iso.org/standard/83389
- Internet Engineering Task Force, RFC 6350, "vCard Format Specification," Simon Perreault, August 2011. The standard format for electronic contact cards recognized by all major mobile and desktop address books; supersedes RFC 2426 (vCard 3.0). datatracker.ietf.org/rfc6350
This article is educational. Payment-system, security, and regulatory details vary by country and change frequently; always consult the original specification and a qualified information-security professional for production deployments. Read our editorial process →