QR Code Versions: From Version 1 to Version 40

The short answer

A QR code “version” is not a software release or a revision of the spec — it is the size of the grid. The QR standard defines 40 versions, numbered 1 to 40, where each version is a slightly bigger grid: version 1 is 21×21 modules, version 2 is 25×25, and every version adds four modules per side, all the way up to version 40 at 177×177 modules. Which version you get is not a choice you make directly; it is decided for you by how much data you encode and which error-correction level you pick — the encoder uses the smallest version that fits your payload at your chosen level.

The practical consequence is the capacity trade-off: more data needs a higher version, a higher version means more modules, and more modules mean a physically larger code at the same print size (or a denser, harder-to-scan code at the same physical size). That is why short links are the single best QR habit — a short URL lands at a low version that scans easily even small, while a long URL can push you to a high version that needs more print area to stay scannable. This page is the version/size complement to our qr code size guide (print sizing) and our how many characters can a QR code hold guide (capacity by mode); our qr best practices guide ties the two together.

What a QR code version actually is

Every QR code is a square grid of dark and light modules, and the version number is simply the size of that grid. Version 1 is the smallest at 21 modules wide by 21 modules tall (441 modules total); version 2 is 25×25; version 3 is 29×29; and so on, adding exactly four modules per side at every step. Version 40, the largest the standard defines, is 177×177 — 31,329 modules. The progression is perfectly linear: the grid size in modules is 17 + 4 × version, so version 10 is 57×57, version 20 is 97×97, version 30 is 137×137.

Bigger grids exist for one reason: to hold more data. A version 1 grid has only a few dozen usable data modules after the finder patterns, timing pattern, and format information take their share; a version 40 grid has tens of thousands. The version is the single knob that trades grid area (and therefore capacity and physical size) for the ability to encode a longer message.

What determines the version

Two inputs decide which version your code ends up at: the size of your data payload and your error-correction level. More data needs more modules to store it, which means a higher version. Higher error correction needs more redundant modules on top of the data, which also means a higher version for the same payload. The encoding mode (numeric, alphanumeric, byte, kanji) also plays in, because tighter modes pack more characters per module — a numeric payload stays at a lower version than the same-length byte payload.

You do not pick the version yourself. You give the encoder your text and your error-correction level, and the encoder walks up from version 1 until it finds the smallest grid that fits your payload plus its error-correction data at your chosen level. That is why a one-line URL prints as a small version-3-or-4 code while a full vCard can land at version 10 or higher — the content, not a menu setting, chose the version.

The capacity trade-off: more data means a bigger, harder-to-scan code

The version/capacity relationship is the core trade-off in QR codes. As the payload grows, the encoder climbs to a higher version, the grid gains modules, and at a fixed physical print size each module gets smaller. Smaller modules are harder for a camera to resolve — below a certain size the scanner simply cannot tell one module from the next, and the read fails. So a high-version code that packs in a long URL is not just bigger; it is more fragile at small print sizes.

This is why the two headline QR habits reinforce each other: keep the payload short so the version stays low, and print the code large enough for the scan distance so the modules are big enough to read. A version-4 code of a short link scans fine at business-card size; a version-20 code of the same link with a huge tracking query bolted on can fail at that same size because its modules are several times smaller. Our how many characters can a QR code hold guide covers the per-mode capacity numbers; our qr best practices guide covers the print-size habit.

The version field in the format information

The version is not just a property of how the code was generated — it is recorded inside the code so a scanner can read it back. Every QR code carries a small “version information” block (from version 7 upward) near the alignment patterns, encoding the version number with its own error correction so the scanner can confirm which grid size it is looking at before it samples the data. Below version 7 the grid is small enough that the scanner derives the version directly from the module count, so the explicit block is omitted to save space.

There is also a separate “format information” block next to each finder pattern that records the error-correction level and the mask pattern, but not the version. The version and the format are distinct pieces of metadata: the version fixes the grid size, the format fixes the error-correction level and mask, and together they let the scanner set up its sampling grid correctly before it reads a single data module.

How to pick the right version (let the encoder do it)

You almost never choose a version by hand — the encoder picks the smallest one that fits your data at your chosen error-correction level, and that is the right default. What you control is the two inputs: keep the payload short (use a short link, trim tracking parameters, pick the tightest encoding mode) and pick the error-correction level deliberately (M by default, H for logos or wear, L only for maximum capacity in a clean setting). Shortening the payload is the only reliable way to push the version down, because lowering the error-correction level buys back capacity but at the cost of resilience.

The scannability rule that follows from this is to size the print for the version you actually get, not the version you wish you had. A high-version code is not broken; it just needs more physical area so each module is large enough to read. If a code will not scan and you discover it landed at a high version because of a long payload, the fix is almost always to shorten the payload so the version drops, not to print the high-version code even larger. Our qr code size guide covers the 1/10 scan-distance rule that turns the module size into a print size.

Version and size at a glance

The table below shows how the grid grows with the version, roughly how much byte data each can hold at the lowest error-correction level (L), and the scannability note for each. Higher error-correction levels hold less at the same version.

How QRForge handles the version

QRForge’s encoder selects the smallest version that fits your payload at your chosen error-correction level automatically, so you never set the version by hand — you just enter your content and the right grid size appears. The live preview shows the resulting code, so you can see when a long payload pushes the grid dense and small, and shorten it before you export. The same encoder drives all three export formats (SVG, PNG, and EPS) so a vector print and a raster screen image are always the same version for the same content.

The two habits that keep the version low are the ones throughout this guide: keep the payload short (short links, trimmed parameters) and choose the error-correction level deliberately (M by default, H for logos and wear). When you add a centered logo, keep it in the middle of the data area at level H and the 20–22% width rule from our qr code with logo guide, then run the final exported image through the free /decode helper to confirm the payload round-trips and scan-test on a real phone before a print run. Pair those with the sizing habit from our qr code size guide and the capacity numbers in our how many characters can a QR code hold guide, and the version stays as low as your content allows — which is what keeps the code scannable.