
A kids' menu comes back from the printer with the QR code drawn as an outline grid, every square waiting for a crayon, and a line inviting children to color it in and scan it. It is a charming idea. As printed it does not scan before it is colored and will not scan afterward either, and the reason is one sentence long: a decoder does not see color, it sees light against dark. A box of felt-tips changes lightness, which is the only variable the code is made of.
That does not kill the idea. It means the sheet has to be built so the parts a child can reach carry no meaning, and the parts that carry meaning are finished before the crayon arrives.
What the decoder is actually reading
The first real step in decoding is thresholding: every pixel is sorted into dark or light, and everything else is discarded. A module lighter than the local cutoff is a light module, whatever hue it happens to be. There is no third state and no allowance for intent.
The rule for a coloring sheet follows directly. A dark module colored in a light color becomes a light module, and the bit it was holding flips. Yellow, pale pink, sky blue, orange, mint all read as light. A child filling the dark squares from the cheerful end of the pencil case is not decorating the code, they are rewriting its data.
The corollary is the useful half. A dark module colored in a dark color is still a dark module. Navy, deep purple, dark brown, forest green, maroon: fill a dark square with any of those and nothing changes at the threshold. Which color pairs survive is the same question in another setting, with the same answer: lightness, never hue.
The three corner squares are not negotiable
Before a decoder reads a bit it has to find the code, and it does that by hunting for the three large squares in the corners. A scan line crossing one passes through a specific sequence of dark and light runs, in proportions of roughly 1:1:3:1:1. That signature is how a finder pattern is recognized at any size or angle.
Color one in with a pale marker and the ratio breaks. The pattern stops being findable and detection fails before decoding is attempted. Worse, the ring of light space inside each finder pattern is a structural part of it, and exactly the sort of gap a child fills in because it looks like an empty box.
Two more structures share that status: the timing patterns, the alternating line between the finders along the top row and left column, and from version 2 upward the smaller alignment squares inside the data area. The anatomy of these patterns shows where each lives.
None of these are repaired by error correction, which rebuilds the data region only. Damage to the structure is not damage, it is the code ceasing to be locatable.
Coloring around the code is free, until the quiet zone
Here is the genuinely unrestricted part. The margin of clear light space around the symbol is four modules wide in the specification, and it is a working part of the code rather than a design allowance. Inside that margin, nothing may be colored. Outside it, everything may: a child can fill the rest of the page right up to the edge of the quiet zone with no effect on the scan whatsoever.
Which points at the honest design: not a colorable code, but a colorable page with a finished code sitting in it. Draw a visible boundary, a keyline or a change of background, at least four modules out and preferably further, with everything colorable on the far side. Children respect a drawn line considerably better than an instruction. What eats a quiet zone covers how this margin disappears in ordinary print work, and a coloring sheet is the most predictable way of all.
What error correction buys you, and what it does not
Every QR code carries redundant codewords. The four levels recover roughly 7, 15, 25 and 30 percent of the symbol's codewords at L, M, Q and H. Our generator produces every code at level H, the highest available.
That budget is a buffer for slips rather than a license. A module read as the wrong value costs about twice as much of it as a module known to be missing, and a colored-in module is always the expensive kind: the reader cannot tell it was tampered with, it just gets a value that disagrees with the check data. Codewords also sit in compact blocks of eight modules, so a child coloring a contiguous patch destroys whole codewords rather than scattered bits. The budget is also shared with the fold, the spilled juice and the printer. How the levels trade against capacity has the arithmetic.
The practical reading: level H forgives a child who strays over two or three module edges. It will not forgive a child who colors the code in yellow.
Designing a sheet that survives
In the order that matters:
- Print the code finished. Dark modules as solid dark fill, not outlines. A hollow square with a keyline around it reads as light, so an outline-only code is not a code yet. It becomes one only if every square gets filled correctly, a gamble taken on behalf of a six-year-old.
- Make the modules big. Shorten the destination to the shortest redirect available, which pushes the symbol toward version 1 or 2 and makes each module as large as it gets, then print it larger than the layout wants. A crayon line is a couple of millimeters wide, and a module has to be comfortably wider than the tool crossing its edge.
- Name the colors. Print the instruction as a choice rather than a free-for-all: three or four dark pencils shown on the sheet, and a line telling the child to use those. Naming them is the difference between a working idea and a broken one.
- Keep the corners out of play. Print the three finder patterns and the timing lines as solid, clearly finished artwork. Do not outline or number them, and if the sheet has a legend, mark them as outside the activity.
- Draw the boundary, well outside four modules, with every colorable illustration on the far side. Keep the reverse light too: on thin stock a dark illustration behind the code shows through into the quiet zone. Paper choice covers show-through and ink spread, which both hit a coloring sheet harder than a normal print job.
Where this earns its place
Kids' menus, activity sheets at a museum or library, a school worksheet, a party pack. The code usually points somewhere stable: a menu, a video, a page for parents.
For restaurants, put the code on the menu side and the coloring on the other, and let the child turn the sheet over. For classroom use, education codes covers the sheet-per-table pattern. And making a code by hand is the neighboring craft: drawing one from scratch on grid paper works, for the same reason coloring one in does not.
Every code we generate is dynamic, so the destination behind a sheet can change after it is printed, on the paid plan. That matters more here than on most print jobs: an activity sheet lives in a drawer for a year and a seasonal menu does not. Building and styling is free and needs no login; downloading the file needs a free account.
Test it with an actual crayon
Not with a swatch, and not in your head.
- Print the sheet at final size on the real stock.
- Color one copy the way a careful child would: dark colors, inside the lines.
- Color a second the way a real child will: over the edges, one square missed, a finder pattern given a friendly yellow center.
- Scan both, on two phones from different makers, at the distance a parent will hold the sheet.
- If the careless copy fails, the modules are too small. Size up and print again.
The first copy tells you very little. The second copy is the test. If it reads, the sheet is ready; if it does not, move the coloring off the code and onto the page around it, which was the safer design all along.

