UseQR vs the qrcode npm package

Library vs product: the honest framing

The qrcode package on npm is a library: MIT-licensed, widely used, downloaded millions of times a week, and it does one thing well, turn a string into a QR matrix and render it as PNG, SVG or a terminal string. UseQR is a product: a generator, an API, payload builders and a verification loop. Comparing them as rivals is a category error, so this page is a decision matrix instead.

If you are writing JavaScript and the requirement is "render this string as a QR code", install the library. That is what it is for, and we would be wasting your time suggesting otherwise.

import QRCode from "qrcode";
await QRCode.toFile("out.png", "https://example.com", { errorCorrectionLevel: "M" });

No network call, no third party at runtime, versions pinned in your lockfile. Our JavaScript guide uses it, and the Node guide covers the server-side variants.

Where the library stops

The library encodes strings. Everything before and after the string is yours to get right, and that is where the failure modes live:

• Payload construction. WIFI:T:WPA;S:Café Guest;P:p@ss;; has escaping rules. UPI has a VPA format and NPCI field semantics; EPC has an IBAN checksum; vCard has version quirks that decide whether iPhones import the contact correctly. The most common QR bug in production is a well-rendered code containing a malformed payload.
• Verification. qrcode renders; it does not read back. A logo overlay, low contrast or aggressive styling can produce an image that will not scan, and nothing in the render path will tell you.
• Styling. Round modules, custom eyes, embedded logos, not the library's job (that gap is what qr-code-styling addresses).
• Non-developers. The marketing team cannot npm install.

What UseQR adds, concretely

• Typed payload endpoints built from the real specs: /api/v1/wifi?ssid=…, /api/v1/upi?pa=…, /api/v1/epc?iban=…, validation errors arrive at generation time with a fix field, not at scan time.
• A verify loop: every code is rendered and decoded back before delivery, and GET /api/v1/verify does the same for any payload, useful in CI even when the rendering itself is done by the npm library.
• Zero dependencies for scripts, CI jobs, spreadsheets and 1,000-item batches, one HTTP call, no toolchain.
• A UI for everyone on the team who is not you.

And because there is no key and no account, adding UseQR to a project is one HTTP call rather than a procurement decision.

The decision matrix

Situation	Use
Rendering QR codes inside a JS/Node app you ship	qrcode npm
Offline or air-gapped generation in code	qrcode npm
WiFi/UPI/EPC/vCard payloads that must be spec-correct	UseQR endpoints, or its payload code as reference
Styled codes with a logo that must still scan	UseQR (styled + verified)
One-off codes, or codes made by non-developers	UseQR
Shell scripts, CI, no-dependency automation	UseQR API
Proving a generated image actually decodes	UseQR verify endpoint, even for library-rendered codes

The genuinely common pattern is both: the library renders in-app, and the API's decode and verify endpoints act as the test harness.

FAQ

Should I use the qrcode npm package or a QR API?

Inside a codebase you control, prefer the library, no runtime network dependency and full control. Use an API when you want zero dependencies, typed payload validation, styling with verification, or a UI for non-developers.

Is the qrcode npm package free for commercial use?

Yes. It is MIT-licensed, like most of the mainstream QR libraries, and is one of the most widely used packages in the ecosystem.

How do I know my library-generated QR code actually scans?

Rendering succeeding proves nothing about scannability. Decode the output with an independent reader (a verify endpoint or a decoder in CI) especially after adding logos, colours or non-standard styling.

Can I build WiFi or payment payloads with the qrcode package?

The package encodes whatever string you give it, so yes, but the string format is your responsibility. WiFi escaping, UPI fields and IBAN checksums are where hand-built payloads usually go wrong; use a spec-validated builder for those.