Keepsake Studio

New here? The guide How the studio composes a keepsake walks through every control in the editor — what each setting changes, what it can never change, and why. This page is the shorter version: what the Studio makes, the rules its engines enforce, and where its promises stop. All the guides are listed further down.

These are not mockups. Each example below was composed at build time by the same engine that runs in the editor, encodes a real link at error-correction level H. Any camera app that reads QR codes reads these — try it.

Reading the examples

Every example is a standard QR symbol at error-correction level H — this engine's rule for every artistic style, because decoration spends decode margin and only the ~30% recovery of EC-H leaves enough. The encoder then picks the smallest symbol that holds the content at that level. The wedding frame and the bare heart code both encode https://keepsakeqrcodes.com/, which fits a version 4 symbol of 33 × 33 modules. The proposal example encodes a longer link, https://keepsakeqrcodes.com/studio/, and needs version 5 (37 × 37); the classic frame encodes https://keepsakeqrcodes.com/features/ at version 5 (37 × 37). That is the honest trade-off in miniature: a few more characters, a denser symbol.

Around every symbol sits the quiet zone the standard requires — 4 light modules on each side, always rendered and never optional — so the wedding code actually occupies 41 × 41 modules of its white panel. The frame art around the panel is drawn below it, and the code's own markup is nested inside the composite byte for byte, so no caption, sprig or heart can touch a module by construction.

The bare heart code shows the engine's second rule. Of its 572 dark modules, 116 belong to the corner finder patterns and the alignment pattern (the alignment grid for a version 4 symbol runs through module positions 6 and 26, mirrored from the encoder's own table) and are drawn as classic squares. The other 456 are drawn as hearts spanning 0.97 of their cell, so a scanner's sampling grid still reads each cell as decisively dark. Both finder and alignment patterns stay classic squares under this engine's rule; restyling alignment patterns breaks decoding outright, so the engine never does it.

• Wedding photo shares — a framed code on each table that opens your shared album, so guests add their photos in one scan;
• Memorial tributes — a quiet, dignified code for an order of service or memorial card that opens a tribute page, photo collection, or guestbook;
• Milestones — anniversaries, graduations, new arrivals: a code that opens a video message, a playlist, or a page you made for the day.

Every code the Studio produces is static: your destination is encoded directly in the image, with no redirect through our servers. A downloaded keepsake is a plain image file that does not depend on this site, an account, or a subscription.

A project in the editor is a small, fixed set of choices: one of 6 occasions (Wedding, Memorial, Anniversary, Graduation, New arrival, Celebration), a link or a hidden message as the content, one of 6 frame choices — the 5 templates (heart, floral, ring, classic, confetti) or no frame at all — a 3-color palette, a caption, classic or heart modules, and the photo-woven switch. A fresh project opens as a wedding with the floral frame and a link; each occasion suggests a template (Wedding → floral, Memorial → classic, Anniversary → heart, Graduation → confetti, New arrival → heart, Celebration → confetti), and the suggestion is only that — every template stays available for every occasion. The composition guide takes each of these in turn.

Decoration spends decode margin, so the Studio refuses to guess. Every render is rasterized and decoded with a real QR decoder in your browser; downloads unlock only when the decoded bytes match your content exactly — the decode-verify promise. Photos for photo-woven codes are processed on your own device and never uploaded; when you save a project, the saved record contains the project's settings and the composed design — the working photos themselves are not uploaded.

Verification runs at 3 raster sizes — 800, 1200, 1600 px — rather than one, because a single fixed raster can false-negative through sampling resonance: a render that happens to fail at exactly one size can decode cleanly at the sizes either side of it. The “Verified scannable” badge is therefore earned when at least 2 of the 3 rasters decode to an exact byte match against the content you entered, and the verdict names the sizes that passed.

How to read a verdict

Three fictional outcomes for the bare heart code above, each sentence produced by the verification engine itself:

• Every raster decodes — “Verified scannable at 800, 1200, 1600 px (3 of 3 rasters) — decoded back to your exact content.”
• One raster misses — “Verified scannable at 800, 1600 px (2 of 3 rasters) — decoded back to your exact content.” This is the resonance case the multi-raster rule exists to absorb; the download is allowed.
• Two rasters miss — “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.”

A render that decodes to different content than you entered is reported ahead of every other failure, because such a render is never safe to use. And a verdict is a statement about your browser's raster of this exact artwork, not about a printer: it cannot see paper, ink, glass or lighting, which is why the next line has always been on this page.

Before you print: always test a keepsake with a real phone camera at the size you plan to print. Scanning depends on print quality, size, and lighting — a ten-second test protects a keepsake that may be photographed for years.

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 — the version 4 and version 5 examples above are the same rule applied to links of different lengths. Where a composition choice affects scannability, the studio surfaces it rather than silently accepting it.

Contrast is computed, not guessed, with the WCAG relative-luminance formula. The engine's warning threshold is 4.5:1, and the artistic engine rejects anything below it rather than merely warning. The palette never recolors the modules themselves; each module style keeps its own measured default. Classic modules — the wedding and classic frames above — are drawn in the shared renderer's default black, #000000, on the white panel at 21.00:1. Heart modules — the proposal frame and the bare heart code — use this engine's deep-rose default, #881337, at 9.57:1. Both clear the 4.5:1 rule. Frame colors never touch the code, which is why a pale secondary is fine as decoration: the floral palette's #86efac reaches only 1.40:1 on white. Ask the engine to draw the heart modules themselves in that color — a fictional misuse the editor does not offer — and it refuses: “Artistic styles require at least 4.5:1 contrast (got 1.40:1) — decoration already spends decode margin.” For reference, the default frame primaries sit at heart #be123c 6.29:1, floral #15803d 5.02:1, ring #a16207 4.92:1, classic #1f2937 14.68:1, confetti #be123c 6.29:1.

Photo-woven codes add one more limit. Each data cell keeps a pure, code-colored center square at 0.5 of the cell side that scanners treat as authoritative, with the photo quantized to three tones around it at luminance thresholds 85 and 175 on a 0–255 scale — and the engine accepts the photo only on symbols up to version 4, about 34 characters of plain text, fewer with emoji or accents. Denser symbols shrink those centers below what a decoder can rely on, so the engine rejects the combination outright and says why, rather than producing a code that would fail verification.

Size is a readout, not a recommendation. The engine defines 3 PNG presets and computes each one's physical size at 300 DPI:

• 512 px — 1.71 in × 1.71 in (43.3 mm × 43.3 mm) at 300 DPI
• 1024 px — 3.41 in × 3.41 in (86.7 mm × 86.7 mm) at 300 DPI
• 2048 px — 6.83 in × 6.83 in (173.4 mm × 173.4 mm) at 300 DPI

The editor's download menu offers the two larger presets; the SVG export scales to any print size without pixelation. Neither number is a scan guarantee for a given printer — that is what the proof print is for.

Signed in, “Save to my studio” keeps a project — its content, frame, palette, caption, and composed artwork — in My projects, where you can reopen it in the editor, duplicate it, or delete it. The deal is stated plainly: free projects are kept for 30 days from the day they are saved, and every row shows its own “kept until” date. Downloads are yours forever either way.

The mechanism behind the label is worth stating exactly, as the methodology does. 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 a saved record holds is equally specific. 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. A reopened photo-woven project therefore shows its saved artwork and asks for the photo again before re-editing.

Live Keepsakes is the one part of the Studio that is deliberately not a downloadable file: a signed-in sender writes a message of up to 500 characters for one of 5 reveal occasions, gets a code on their screen, and the message plays on the recipient's phone the moment it is scanned. Being live is a trade, stated plainly: the message is hosted in our database and the keepsake ends 30 days after it is created, and opens are anonymous — the sender sees when, never who. The anonymous read path returns only the occasion, the message and the style; the parser that handles it is an allowlist and structurally cannot return anything else. The two screens are driven by two small state machines that never move backwards, walked through in the Live Keepsakes guide.

Three things sit outside what verification, retention and composition can promise, and the Studio says so rather than implying otherwise.

• Destination longevity. The studio verifies the format of what you encode, not the future of the service it points to. A link whose host removes it 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.

The guide What the studio does not model takes each limit in turn, with what to do instead.

Each guide explains one mechanism of the Studio the way the methodology does — what the engine does, why, and where it stops — with every figure computed at build time by the same code. The full list lives at /guides/.

• How the studio composes a keepsake — the editor state, occasions and default templates, payload types, module styles, frame choices and palettes.
• Error correction, chosen for print — the EC-H rule, what decoration spends, and why longer destinations make denser symbols.
• Composition stays in your browser — what is processed on the device, what a saved project contains, and how to check for yourself.
• How the 30-day retention works — the expiry timestamp, row-level security, the purge, and why downloads are independent.
• How Live Keepsakes reveal — the two state machines, reduced motion, burst counts, and what the public read path returns.
• Decode verification in the studio — the raster sizes, the pass rule, sampling resonance, and what verification cannot promise.
• What the studio does not model — destination longevity, color fidelity, scan counting — and what to do instead.

Want a quick one-off keepsake without projects or accounts? The free generator at KeepsakeCodes.net shares this Studio's verified artistic engine. For utility codes — Wi-Fi cards, vCards, event links — use GenerateQRCodes.net. Both are part of the Sumvia network of free browser tools.