Where Is a QR Code Stored? How QR Codes Store Data

The short answer

The data a QR code carries is not stored on a server, in the cloud, or “on the internet” — it is encoded directly into the printed pattern itself, as a two-dimensional grid of dark and light modules. The camera reads the grid, decodes the bits back into text, and the phone turns that text into an action. No lookup, no connection, no middleman: the code is the data. That is why a printed QR code scans even with the phone in airplane mode, and why a static code keeps working decades after whoever made it is gone.

How much fits depends on the QR version (the grid size, from 21×21 up to 177×177) and the encoding mode (numeric, alphanumeric, byte, or kanji). The headline capacity is about 7,089 digits, 4,296 alphanumeric characters, or 2,953 bytes — covered in our how many characters guide and our qr code content types guide. The one exception to “the data is the pattern” is a dynamic code, which stores only a short redirect link in the pattern and keeps the real destination on a server — covered in the dynamic contrast section below.

The data is the pattern

A QR code is a self-contained record. Every dark module is a 1 bit and every light module is a 0 bit (after masking is undone), and the arrangement of those bits across the grid encodes the payload plus the error-correction redundancy that lets a damaged or logo-covered code still scan. The finder patterns in three corners tell the camera where the code is and how it is rotated, the timing patterns tell it how big the grid is, and the data modules carry the actual text. Nothing about reading a static QR code requires the internet — the phone decodes the image locally, exactly the way it reads a printed paragraph or a 1D barcode.

This is the defining property of a static QR code and the source of every one of its strengths. Because the data lives in the ink, a static code is free to generate (no server to host), private (no scan ever leaves the phone unless the payload is a URL the user taps), and immortal (the code keeps scanning as long as the print survives). The trade-off is that the data is baked in: to change the destination you reprint the code, because there is nowhere to repoint — the destination and the pattern are the same object.

Capacity is set by version and mode

Two knobs set how much data a single QR code can store. The first is the version, which sets the grid size: version 1 is 21×21 modules, version 40 is 177×177, and each version adds four modules per side. A bigger grid holds more bits, at the cost of being harder to scan at small sizes. The second is the encoding mode, which packs characters more or less tightly: numeric mode stores about 3.3 bits per digit, alphanumeric about 5.5 bits per character, byte mode about 8 bits per character, and kanji about 13 bits per character. The encoder picks the tightest mode that fits the data, so a pure-number payload gets numeric mode and a long URL gets byte mode.

The practical capacity numbers come from crossing those two knobs at the lowest error-correction level: a version-40 code at level L holds up to 7,089 numeric digits, 4,296 alphanumeric characters, 2,953 bytes, or 1,817 kanji. Raising the error-correction level trades capacity for resilience, so level H (about 30% redundancy, recommended for logos and wear) holds less. Most real-world payloads are far shorter than the ceiling — a typical URL lands at version 3 or 4 — and the real limit people hit is scannability, not capacity, so keep payloads short. Our how many characters guide works through the numbers, and the qr code content types guide covers which payload format each content type stores.

A static code works offline forever

Because the data is the pattern, a static QR code needs no server, no subscription, no internet connection, and no provider to stay alive. The camera decodes the grid locally and the phone acts on the text — open a URL, join a WiFi network, add a vCard, save a calendar event. For the self-contained payloads that never touch the internet (WiFi, vCard, SMS, email, event, plain text) that is the whole story: the code is a printed string and it works the same in 2025 as it will in 2045. A URL code needs the internet only to load the page after the scan, not to read the code itself.

This is the property that makes a static code the safe default for anything permanent. There is no clock to expire, no account to lapse, no short domain to be sold, no redirect table to be deleted. The code scans for as long as the print survives and the destination (for a URL) still resolves — see our do QR codes expire guide for the full picture. The only way a static code “goes stale” is the ordinary way any printed link does: the page on the other end moves or the domain lapses, one destination at a time, never the whole print run at once.

The dynamic contrast — where a dynamic code stores its data

A dynamic QR code splits the data in two. The printed pattern encodes only a short redirect URL (something like r.example.com/abc), and the real destination lives in a lookup table on a server you control. When a phone scans the printed code, the browser requests the short URL, the server replies with a redirect to the real destination, and the phone follows it automatically. The pattern still carries data — but only the short link, not the destination — which is why a dynamic code can be edited without reprinting: you change the server-side mapping, not the ink.

That split is the root of every dynamic power (editable destination, scan analytics, expiry, password gates, multi-URL routing) and every dynamic cost (a server to run, a paid tier, and the link-rot risk that the server going down breaks every printed copy at once). The data for a dynamic code is therefore stored in two places: the short link in the pattern, the destination on the server. Our dynamic QR code guide covers the mechanism in depth, and the static vs dynamic QR guide is the full trade-off; the table below puts the two side by side.

Static vs dynamic: where the data lives

Here are the two kinds of QR code side by side, with what each one encodes, where the real data lives, and the consequences. The middle column is the key — it is the answer to “where is a QR code stored”, and it is different for a static and a dynamic code.

Does a QR code need internet?

Reading a QR code never needs the internet — the phone camera decodes the printed pattern locally, the same way it reads a barcode or a street sign. What happens after the scan depends on the payload. A WiFi code joins a network offline; a vCard adds a contact offline; an event adds a calendar entry offline; an SMS or email opens a draft offline. A plain-text code shows characters offline. None of those make any network request to read the code.

A URL code is the one case where the internet comes in: the scan reads the URL locally (still no internet for the read), and then the browser needs a connection to load the page — exactly the same as if the user had typed the address. A dynamic code is the same but one step further: the scan reads the short link locally, and the redirect lookup itself needs the internet, so a dynamic code that points at a dead server fails even though the printed pattern is intact. For anything that should keep working without a connection, a static self-contained payload is the answer.

How QRForge stores it

QRForge’s free generator builds self-contained static codes by default, so the data lives in the printed pattern exactly as described above — nothing is uploaded, no server is involved in the scan, and the code keeps working offline for as long as the print survives. Pick a content type, enter your data, style it to match the brand, and export PNG for screens or vector SVG or EPS for print; the preview renders live so you can scan-test before you commit, and the free decode helper confirms the exported image round-trips to the exact payload.

For the edit-and-track case where you want to change the destination without reprinting or count scans, the planned dynamic tier replaces the static payload with a short redirect link on a server you control — the destination moves off the ink and onto the server, unlocking editable destination and the analytics stack. Start with a static code to prove the placement, and step up to dynamic only when editability or tracking is the actual lever. The static vs dynamic QR guide and the dynamic QR code guide cover that trade-off, and the do QR codes expire guide explains why the static default is the safe choice for anything permanent.