Lior Ashkenazi

My framing is that a QR code is a fixed grid of modules with a structure, and most of the decisions are about which version and which error correction level you pick. The version is the grid size, from twenty-one modules square upward in steps of four. It bounds capacity, and it grows with the amount of data and with the error correction level, since correction is paid for in modules that could have carried data. Error correction comes in four levels, and each recovers a stated fraction of the code. That redundancy is what lets a code read with part of it covered or printed badly, and it is also why a high correction level produces a denser code for the same content. The choice is a decision about the printing and handling conditions rather than about the data. Encoding matters more than it looks. Text modes hold fewer characters than numeric or alphanumeric modes, and choosing the wrong one for the content wastes capacity. A URL in the numeric-looking case is a content error that produces an unscannable code rather than a warning. On decoding, the useful tools report the format, the error correction level and the version, and those three together usually explain why a code will not read. I keep a note on which characters need escaping and on the practical limits, since a code holding a very long URL becomes hard to scan at any usable size. Print size is the last variable and the one most often ignored. A denser code needs a larger print to be read at a distance, so raising the error correction level can make a printed code unusable at the size it was designed for.