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.

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 codewords, choose a mask	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 code has a 177×177 matrix versus 21×21 for version 1) and mask selection, which scores up to 8 candidate masks 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 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).

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 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 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).
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.