# QR code generation performance

> Encoding a QR matrix is trivial — microseconds to low milliseconds on any modern CPU. Rendering dominates the cost: building an SVG string is cheap, rasterising a PNG is 10 to 100 times more expensive. Performance only matters in batch jobs, hot API paths and serverless cold starts; for one code at a time, everything is fast enough.

Source: https://useqr.app/docs/developers/qr-code-generation-performance · Last reviewed 2026-08-21 · UseQR is free forever, MIT licensed, no signup.

---

## Where the time actually goes

"Generate a QR code" is three stages with wildly different costs:

| Stage | What happens | Order of magnitude |
|---|---|---|
| Encode | segment data, add [Reed–Solomon](/glossary/reed-solomon) codewords, choose a [mask](/glossary/mask-pattern) | microseconds to low milliseconds |
| Render to SVG | walk the matrix, emit path strings | comparable to encoding |
| Rasterise to PNG | rasterise vector shapes, encode PNG | **10–100× the encode cost**, growing with pixel size |

We deliberately give orders of magnitude rather than a benchmark table: absolute
numbers vary by CPU, runtime, library and payload, and published QR benchmarks age
badly. The *shape* of the cost is stable, and it is the shape that should drive your
decisions.

Two things make encoding more expensive, both modestly: longer payloads (a
[version 40](/docs/reference/qr-code-version-and-module-table) code has a 177×177
matrix versus 21×21 for version 1) and mask selection, which scores up to
[8 candidate masks](/docs/spec/mask-selection-penalty-scores) against penalty rules.
Even so, encoding almost never appears in a profile. Rasterisation always does.

## Consequences

**Prefer SVG when you can.** An SVG is a string — no pixel work, tiny output,
scale-free, and [better for print](/docs/print/why-you-should-print-qr-codes-from-svg)
anyway. UseQR's batch endpoint caps rendered-PNG batches at 100 items but URL/SVG
batches at 1,000, precisely because rasterisation is the expensive stage.

**Rasterise per size, cache the matrix.** The matrix depends only on data and EC
level; pixel output depends on size and styling. If you serve one payload at several
sizes, compute the matrix once and rasterise per request — or better, rasterise once
per size and cache the bytes, since output is deterministic
([caching strategy](/docs/developers/caching-and-cdn-strategy-for-qr-images)).

**Batch cost is rendering cost.** A million-code job spends its time in the
rasteriser and the filesystem, not the encoder. Parallelise across cores and emit SVG
where the downstream tooling allows —
[bulk generation at scale](/docs/developers/bulk-qr-generation-at-scale) covers the
worker-pool pattern.

**Pixel size is a real knob.** PNG rasterisation cost scales with the pixel area, so
a 4096 px render is roughly an order of magnitude more work than 1024 px. Generate at
the size you need, not the maximum you might someday want — the
[size calculator](/size-calculator) tells you what you need.

## When performance actually matters

Honest list — for a single code in a UI, every library and API is effectively instant,
and optimising there is wasted effort. It matters in:

- **Batch jobs** — thousands to millions of renders multiply every per-code cost.
- **Hot API paths** — a QR image endpoint under real traffic wants deterministic
  output and long-lived caching far more than a faster encoder; a cache hit is always
  cheaper than the fastest render.
- **Serverless** — where bundle size and native dependencies affect cold starts more
  than compute does; pure-JS generators keep functions small
  ([details](/docs/developers/qr-codes-in-serverless-functions)).
- **Embedded and low-power devices** — the one context where encoder implementation
  genuinely matters, and where matrix caching buys the most.

One measured data point from UseQR's own pipeline: CI decode-verifies the full
permutation matrix of module styles, eye styles, gradients and EC levels — hundreds of
render-plus-decode round trips — and the decode step, not generation, dominates that
suite's runtime. Decoding is computer vision; generation is arithmetic.

## FAQ

### How long does it take to generate a QR code?
Encoding the matrix takes microseconds to low milliseconds on any modern hardware. Rendering dominates: an SVG string is nearly free, while rasterising a large PNG can take tens of milliseconds. For interactive use, everything is effectively instant.

### Why is my bulk QR job slow?
Almost certainly rasterisation and disk I/O, not encoding. Switch to SVG output if downstream tools accept it, render at the size you need rather than the maximum, and parallelise across CPU cores with a worker pool.

### Is SVG faster than PNG for QR codes?
Yes, by a wide margin — SVG generation is string building while PNG requires rasterising every pixel, and the gap grows with image size. SVG is also smaller to store and sharper to print.

### Do longer URLs make QR generation slower?
Slightly. Longer payloads mean higher versions with larger matrices and more error-correction maths, but encoding stays in the low-millisecond range even at version 40. The real cost of long URLs is scan reliability, not generation speed.

## Try it

- https://useqr.app/url
- https://useqr.app/bulk
- https://useqr.app/validate