Methodology & Accuracy
A keepsake is a bad place for an unreliable QR code. This page documents how the studio's codes are produced, which conventions the composition follows, what deliberately stays on your device, and how the 30-day retention promise is actually enforced — so you can judge exactly how far to trust the object you print.
Standards-compliant encoding
Every code is a standard QR symbol as specified by ISO/IEC 18004, produced by a tested encoder — the same encoding discipline used across the Sumvia network. There is no proprietary format and no wrapper: any camera app that reads QR codes reads these. The destination you encode is placed in the symbol exactly as entered, with no shortening, tracking parameters, or redirection added.
Error correction, chosen for print
QR codes carry redundancy so a partially obscured or imperfectly printed symbol still scans. Keepsake codes default to a higher error-correction level than screen-only codes need, because keepsakes are printed, framed behind glass, photographed at an angle, and read in candlelight. The honest trade-off: more redundancy means a denser symbol, so very long destinations plus high correction can produce codes that need to be printed larger. Where a composition choice affects scannability, the studio surfaces it rather than silently accepting it.
Composition happens in your browser
Framing, captions, styling, and any photos you work with during composition are processed by JavaScript on your own device. Nothing you type or place on the canvas is transmitted in order to render a preview or produce a download. When you save a project to your account, the saved record contains the project's settings and the composed design — the working photos themselves are not uploaded. This is a design constraint, not a configuration: the site is static and has no server that could receive them.
How the 30-day retention really works
Saved projects carry an expiry timestamp set 30 days ahead at save time, and the database's row-level security policy makes expired rows invisible to every client — the policy that grants you access to your own projects also requires them to be unexpired. Expiry is therefore not a scheduled cleanup job that might lag or a client-side filter that could be bypassed: at the moment a project expires it stops being readable, and a background purge permanently removes expired rows. Download anything you want to keep; the downloaded file is independent of all of this.
What the studio does not model
- Destination longevity. The studio verifies the format of what you encode, not the future of the service it points to. A photo-album link that its host deletes in five years stops working regardless of how well the code scans — for the longest-lived keepsakes, point codes at destinations you control.
- Print-shop color fidelity. Contrast and sizing guidance follows scanning practice, but printers, papers, and inks vary. Test a proof print before a large run.
- Scan counting or analytics. Static codes cannot report scans, and the studio adds no tracking to your destinations. If you need scan counts, that is a different product — we would rather say so than quietly add a middleman to your keepsake.
Tested, and worked examples can't drift
The studio's logic — encoding, validation, expiry labeling, project handling — is implemented as small, typed functions covered by automated tests, and any worked example shown in page copy is produced at build time by the same code that powers the tools, so documentation cannot silently disagree with behavior. If you believe a code is malformed or a claim on this page is wrong, that is exactly the report we want: see the contact page. Confirmed issues are fixed in the engine and locked in with a new test.