What the studio does not model

The methodology page names three things the studio deliberately does not model: the longevity of the destination a code points to, the colour fidelity of a print shop, and scan counting. This guide takes each limit in turn and shows where the engine's checks stop — what the encoder, the contrast check, the print-size readout and the decode verification actually compute — so that none of their labels is read as a promise it does not make. Every figure below was produced at build time by the same engine that runs in the Studio, on fictional inputs that are named as such. It is one of the Studio guides.

Destination longevity: the encoder checks a format, not a future

When you enter a link, the encoder takes the text exactly as typed, chooses a QR version that holds it at the requested error-correction level — or, as the methodology notes, a higher level when that fits in the same version — and lays out the modules. Take a fictional album link on a third-party photo host, https://photos.example.com/albums/ella-and-sam-2027 (51 characters): it encodes as a version-6 symbol, 41 modules a side at level H, which with the mandatory quiet zone of 4 modules on every side is 49 modules across. A second fictional link on a domain the sender owns, https://example.org/ella-and-sam/album/, encodes as a version-5 symbol of 37 modules. The encoder cannot tell these two apart in the way that matters: both are well-formed text, both encode, and in both cases the recorded text is the input character for character — a check the build itself performs.

Verification is just as literal. Every artistic render is rasterised at 800, 1200, 1600 px and each raster is decoded; the badge is earned when at least 2 of the 3 rasters decode to an exact byte match against your content. A fictional run in which the 800 px and 1600 px rasters decode and the 1200 px raster misses produces the verdict “Verified scannable at 800, 1600 px (2 of 3 rasters) — decoded back to your exact content.” A run in which only the 800 px raster decodes produces “Cannot verify: this render decoded at only 1 of 3 raster sizes (at least 2 must match). Do not print it — adjust the style (larger size, stronger contrast, shorter content, or a calmer photo) until verification passes.” The comparison itself is a byte comparison: the fictional hosted link compared with the text the encoder stored is a match; compared with the owned link it is not a match. This path runs in your browser, as the methodology states: the decoder reads pixels, the comparison reads bytes, and neither fetches the destination — which is why a verified code can point at a service that later removes the page.

A hidden-message keepsake sits outside this limit for a structural reason: with the text payload type the message itself is the content of the symbol. A fictional message — “Our photo album is on the table by the window.”, 46 characters — encodes as a version-6 symbol of 41 modules, and there is no destination to outlive — the words are the symbol's content, and any camera app that reads QR codes reads these. For a link payload the content is the address, and the address is all the studio can check.

What to do about it is the methodology's own sentence: “for the longest-lived keepsakes, point codes at destinations you control.” The studio cannot judge control — it is a property of the destination, not of the code. The common misreading is to treat “Verified scannable” as a statement about the link's future; it is a statement about bytes at the moment of rendering, and the verification guide walks through the verdicts.

Print-shop colour fidelity: the contrast check measures hex values

The engine's contrast rule is a computation on colours as numbers. It takes the foreground and background hex values, converts each to WCAG 2.x relative luminance, and divides; artistic styles require a ratio of at least 4.5:1 and reject anything lower rather than warn. The heart-module default colours — the engine's defaults, not an input of ours — measure 9.57:1 against the engine's default white background. A fictional mid-grey foreground of #767676 on white measures 4.54:1 and passes; a slightly lighter #8a8a8a measures 3.45:1 and is refused, with the engine's own message: “Artistic styles require at least 4.5:1 contrast (got 3.45:1) — decoration already spends decode margin.”

Those digits describe the file — the colours in the SVG or PNG you download — and nothing about what a particular printer, paper and ink will make of them. The frame palette is one step further removed still: as the features page notes, palette colours touch only the frame art, the panel's border stroke and the caption — never a module — while the code sits on its own opaque white panel composed above the decoration, so recolouring the palette cannot alter the modules' contrast against their panel. The methodology's limit is therefore exact: “Contrast and sizing guidance follows scanning practice, but printers, papers, and inks vary. Test a proof print before a large run.” The proof print is the measurement the studio cannot take for you.

The print-size readout is arithmetic: inches equal pixels divided by 300, millimetres follow from inches, and the label states the assumption in its own text. For the PNG presets the engine offers, rendered for the fictional hosted link above:

The module column is the same arithmetic applied to one cell: 2048 pixels across 49 modules gives 41.8 px per module, which the readout converts to 3.54 mm at 300 DPI. A 512 px file printed at exactly 300 DPI measures 1.71 inches a side; printed at any other resolution it measures something else, and the studio cannot know which resolution a print will be made at. The error-correction guide explains why longer destinations make denser symbols and therefore smaller modules at the same export size.

Scan counting: a static code has nothing to report

The methodology states that the destination you encode “is placed in the symbol exactly as entered, with no shortening, tracking parameters, or redirection added,” and the encoder's output is the proof: the fictional hosted link goes in at 51 characters and the model records 51 characters of identical text. The destination is the symbol's content; nothing operated by the studio sits between the symbol and the destination, so there is no point at which a scan could be observed, let alone counted. Decode verification runs in your browser, as the methodology states, and the downloaded file is a plain image. That is the whole of the methodology's sentence: “Static codes cannot report scans, and the studio adds no tracking to your destinations.”

One place in the studio can report an open, and it is instructive because it is the exception. A Live Keepsake is hosted: its code encodes a page on this site under /r/ — for a fictional reveal id, https://keepsakeqrcodes.com/r/?k=0f1e2d3c-4b5a-4987-8a6b-5c4d3e2f1a0b — and because the destination is a page the site serves, the sender's screen can show a status line built from open events. With no events it reads “Not opened yet”; with two fictional opens and one love back, on a fixed clock, it reads “Opened 2 times · last 9:14 PM · 1 love back”. That is a count of opens of the hosted reveal page, not of scans of a destination you chose. The anonymous read path returns only the occasion, the message and the style; the sender's screen receives open and love-back events carrying only a kind and a time — never who opened it or from where — as the features page states. A live keepsake, as the methodology states, “carries its own expiry instant on its record; after that instant the reveal link goes dark”, and the Live Keepsakes guide walks through both state machines.

For everything you download, the methodology's answer stands as written: “If you need scan counts, that is a different product — we would rather say so than quietly add a middleman to your keepsake.” The common misreading runs the other way: that because the studio verifies a code, it must also be watching it. Verification happens in your browser, before you download; the browser guide shows how to confirm that in your network tab.

Reading the studio's labels without over-reading them

Each label the studio shows is the output of one computation. The table collects labels that are easily stretched past what they computed.

The last row belongs to a different mechanism, covered by the retention guide, and is listed because it is misread the same way: the label is about the saved record, and the download is independent of it.

Questions about the limits

Part of the Studio guides. Every figure on this page was produced at build time by the engine that runs in the editor; composition and verification happen in your browser. The methodology page states the three limits this guide explains, alongside every convention the codes follow.