Methodology.

What this page is

Each tool on this site is a thin interface over a small, pure engine, and the engines carry their rules as named constants and documented functions. This page states those rules in plain language, in the engine’s own terms. Every number below is one of three things: a constant imported from the engine, a value the engine computed at build time from a fixed example input, or a platform or standards figure read from the site’s specs registry with the date it was checked against official documentation. Where an engine rule exists only inside a function or a documentation comment rather than as an exported constant, the page describes it in words, without digits or counts, and says so. Nothing else is typed in by hand, and the module-level checks fail the build if an example stops behaving as the prose says, so the page cannot quietly drift from the code it describes.

The examples are fictional and labelled as such. Where a tool’s limit is a judgement rather than a measurement, the engine says so and this page repeats it. The guides apply the same rules placement by placement.

QR codes: the quiet zone is always drawn

The QR engine renders a quiet zone of 4 modules on every side of the symbol, and nothing in the interface can disable it. The quiet zone is the required clear margin around the symbol; the engine attributes the 4-module width to ISO/IEC 18004, and the public statement of the same rule is DENSO WAVE’s: “QR Code requires a four-module wide margin at all sides of a symbol.” (source, 2026-10-02).

The example destination https://example.com/launch encodes to a version 2 symbol of 25×25 modules; with the quiet zone it is 33×33 modules. Since a module is the smallest square in the pattern, the quiet zone scales with the code rather than being a fixed pixel margin.

Error correction: M by default, H whenever a logo is present

Without a logo the engine encodes at level M unless another level is chosen; the example destination above came back at level M. The four levels tolerate ≈7% (L), ≈15% (M), ≈25% (Q) and ≈30% (H) erroneous codewords, as stated in the reference encoder the engine vendors (source, 2026-10-02). A higher level can cost a larger symbol: the example destination is version 2 at level M and version 4 at level H.

When a centre logo is present the engine forces level H and reports that it did so: the same destination encoded with a logo returns level H, with the flag ecForcedByLogo set to true, at version 4. The logo destroys modules that error correction must reconstruct, so the choice is not left to the user. The artistic styles — heart modules, photo-woven halftone and framed composites — require level H as well, and reject any model encoded lower.

A common misreading: the level the engine reports can be higher than the level asked for, never lower. The reference encoder raises the error-correction level whenever doing so does not increase the version, so short text requested at L may come back at M, Q or even H at the same symbol size. The ecLevel on the result is the level actually encoded, and ecForcedByLogo is true only when a logo overrode the request.

The logo area cap is measured, not theoretical

A logo knockout — the image plus its pad, everything that obscures modules — may cover at most 16% of the symbol area excluding the quiet zone, and the default request is 12%. The cap is recorded in the engine as a measured decode margin: with a worst-case opaque dark logo on clean rasters, the decoder fails at a larger area on the symbol sizes the measurement covers, while 16%decodes. The failing area and the symbol versions are recorded in the constant’s own documentation comment, not as exported constants and not in a test on disk, so this page does not restate them as figures. The ≈30% recovery ceiling of level H does not translate into ≈30% of the area, because a centred knockout produces burst erasures that consume the margin faster than scattered damage would. The default is held below the cap so real prints keep decode headroom.

Requests above the cap are rejected rather than silently clamped. Asking for a fictional 20% returns the error: “A logo may cover at most 16% of the symbol area — above that, the code stops decoding even on a clean scan.”

Photo-woven codes: pure centres and a version cap

The halftone style quantises a photo into the data modules while keeping a pure, module-coloured centre square at 50%of each cell’s side — the measured floor: the engine records that the one smaller centre it tested failed to decode, and says nothing about the values in between. Finder, alignment and timing patterns and the quiet zone stay fully pure, and no logo may be stacked on a halftone code. Heart modules cover 0.97of their cell so a reader’s sampling grid still sees each cell as decisively dark. The framed composites — heart, floral, ring, classic, confetti — never touch the code: the rendered symbol is nested verbatim on an opaque panel above the frame art.

Payload complexity for a halftone code is capped at version 4, because denser symbols shrink the authoritative centres below decode viability. The engine’s character guidance derived from that cap is 34 ASCII characters. In practice, https://example.com/launch at level H is version 4 and fits; a longer destination such as https://example.com/campaigns/autumn-launch/tickets?source=poster is version 8 at level H and is refused for the photo-woven style. This is why the QR page asks for a short link.

Contrast: a computed warning at the WCAG AA threshold

The QR engine computes the WCAG 2.x relative-luminance contrast ratio of the chosen foreground and background and warns when it falls below 4.5:1 — the Level AA minimum for text, which WCAG states as “The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:” (source, 2026-10-02). Readers binarise the image, so contrast below that level measurably hurts decoding. Black on white measures 21.00:1 and passes; a mid-grey on a lighter grey (#777777 on #999999) measures 1.57:1 and warns.

Polarity is checked separately: white on black measures the same 21.00:1 as black on white, yet the engine flags it as inverted, because light modules on a dark background are not reliably read by all scanners. The classic QR tool warns; the artistic engine rejects.

Print size is arithmetic

PNG export offers 3 pixel sizes, and the print readout is pixels divided by 300 dots per inch, then millimetres from inches:

• 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 SVG export carries a nominal pixel width (33 modules at the default module size is 264pixels for the fictional destination) but is drawn as one path in module units inside a viewBox, so it rescales to any print size without resampling, which is why the Studio’s package carries the code as both PNG and SVG.

Payload types, each built to a named specification

The QR maker’s builders are pure functions: each validates its fields and returns either the exact string to encode or a list of per-field errors, so the form can mark the one input that is wrong. The formats follow the sources the engine cites: vCard 3.0 (RFC 2426), mailto (RFC 6068), tel with E.164 numbers (RFC 3966), sms with a body field (RFC 5724), geo in WGS-84 (RFC 5870), iCalendar events (RFC 5545), the WIFI: format of the ZXing Barcode Contents wiki and the WhatsApp click-to-chat (wa.me) form (WhatsApp’s own page), all re-checked between 2026-10-02 and 2026-10-05. A URL and plain text are not reshaped: each is validated and then encoded exactly as typed.

Worked on fixed fictional inputs:

• A Wi-Fi network named Cafe;Promo with the passphrase p:ss,word1 becomes WIFI:T:WPA;S:Cafe\;Promo;P:p\:ss\,word1;;— the semicolon, colon and comma are backslash-escaped, as the wiki rule requires: “Special characters \, ;, ,, " and : should be escaped with a backslash (\) as in MECARD encoding”. The network was entered as WPA2 yet the string carries the WPA token: WPA2 and WPA3-Personal both map to it, because the joining device negotiates the strongest protocol itself and a nonstandard token would break parsers.
• An open network named CAFE01 becomes WIFI:T:nopass;S:"CAFE01";;: an all-hex name is double-quoted so readers take it as literal text.
• The phone number +44 20 7946 0958 becomes tel:+442079460958; with the message Save my seat! it becomes sms:+442079460958?body=Save%20my%20seat%21, the body strictly percent-encoded.
• An email to hello@example.com with the subject Launch & party? becomes mailto:hello@example.com?subject=Launch%20%26%20party%3F.
• Latitude 51.5007, longitude −0.1246 becomes geo:51.5007,-0.1246; latitude 95 returns the field error “Latitude must be between -90 and 90.”.
• A URL typed without its protocol returns “Include the protocol (e.g. https://) so scanners recognize the link.” — the URL is validated but never rewritten.

Two builders carry a disclosure the interface must show. For SMS: “Pre-filled message support varies by platform: some phones open the composer with the text, others ignore it. The number always works.” For calendar events: “Calendar QR codes are less reliable than other types: native camera app support is inconsistent, and some phones show the raw text instead of an add-to-calendar prompt. Test on the devices your audience uses.”

Barcodes: verify or compute, then cross-check

The barcode maker renders 6 symbologies: Code 128, EAN-13, UPC-A, ISBN, Code 39, ITF-14. For the retail and carton formats the rule is verify-or-compute: enter the data digits and the engine computes the check digit and appends it; enter the full number and the engine verifies the final digit, refusing a mismatch. On the engine’s own EAN-13 example, 4006381333931 verifies (“Check digit 1 was independently verified.”); its 12 data digits alone, 400638133393, produce 4006381333931(“Check digit 1 was independently computed and appended.”); and the same digits with the last one altered are refused: “Check digit mismatch: the final digit must be 1, not 2.”

Before rendering, a second independent pass re-verifies the check digit of the payload about to be drawn; on the verified example it returns true. ISBNs follow the same path: the engine’s ISBN-13 example 978-0-306-40615-7 is verified and rendered as 9780306406157(“ISBN-13 check digit 7 was independently verified.”); an ISBN-10 is verified against its own check character and converted to that form first. Code 128 and Code 39 carry no check digit here; their rules are character-set and length rules: “Printable ASCII, 1–80 characters.” and “A–Z, 0–9, space, and - . $ / + % only; 1–60 characters.”

The favicon package

The favicon generator renders a set of square PNG icons on a canvas in the browser, from the tab-sized icon up to the large install icon, and never uploads the source. The smaller renders are packed into one ICO file; the install-size renders are repeated as maskable icons, drawn on a solid background with a padding floor the engine fixes for them, applied whenever the requested padding is lower. The requested padding is clamped to a fixed range before any render. A head-markup snippet links the ICO, the smallest PNG favicons, the Apple touch icon and the manifest; the manifest in turn lists the standard and maskable install icons with their purposes. The size list, the padding range and the maskable floor live inside the engine’s render functions rather than as exported constants, so this page describes them in words and does not restate them as figures.

The ICO is assembled from PNG entries directly: the builder writes an ICO header of 6 bytes, a 16-byte directory entry per icon and then the PNG bytes themselves — measured here by building two tiny ICOs and subtracting their payloads (22 bytes of overhead for one entry, 38 for two).

Image conversion: the file's bytes decide, not its name

The converter identifies a source by its signature bytes rather than its extension. The PNG signature (8 bytes, constructed here) is detected as png, the JPEG marker (3 bytes) as jpeg, and a file whose first bytes match nothing returns null and is refused as unsupported, whatever it is named. HEIC and AVIF are told apart by the brands in their ftyp box. Inputs: PNG, JPEG, WebP, GIF, BMP, HEIC, AVIF. Outputs: PNG, JPEG, WebP, AVIF.

Output names follow one rule: poster.heic converted to JPEG becomes poster.jpg; converting poster.png to PNG becomes poster-converted.pngso the source is never overwritten by name. After encoding, the converter detects the signature of its own output and decodes it to confirm the dimensions before offering the download. The output pixel count is held under a fixed megapixel ceiling stated in the converter’s error message; a JPEG target flattens transparency onto the chosen background, and for a source format that can carry transparency it says so in its note, and a GIF, WebP or AVIF source carries the note that animated sources export their first frame — the converter does not test whether the file is animated.

The Tap-or-Scan card

The card builder takes one destination and emits one self-contained HTML document that carries the QR code as an embedded image and a button linking to the same destination. Every text field — title, subtitle, call to action, destination, date line, venue and calendar link — passes through an HTML escaper, while the QR data URL is placed as given and the accent and design colours are checked against a fixed hex pattern instead; so a title such as Autumn Launch <live> & "friends" is written as Autumn Launch &lt;live&gt; &amp; &quot;friends&quot;. The design settings applied to the card are normalised through the same function the Studio uses, so the card’s type and colours match the package it ships in.

Thumbnails: one canvas, 5 templates, one protected layer

The thumbnail maker renders on a fixed 1280×720 canvas with 5 templates: Editorial (Ink gradient and eucalyptus rule); Tutorial (Clear label and structured title block); Interview (Quiet lower-third composition); Minimal (Image-led with restrained typography); Before / after (Measured split-field comparison). A YouTube input is parsed to a single video id — the share form https://youtu.be/dQw4w9WgXcQ?t=42 yields dQw4w9WgXcQ, while a non-YouTube host is refused with “This is not a supported YouTube URL.” — and the maker then tries the platform’s own thumbnail images in order (Maximum resolution, Standard definition, High quality, Medium quality), checking each candidate’s width before accepting it. After export, the blob is decoded again to confirm its dimensions.

The overlay text layer — the kicker and the title — is the one place the site changes a colour at render time. Because the layer is drawn over a photo the design cannot predict, the renderer does not read the photo: it assumes a pure white background behind the type, composites its scrim’s dark tone over that at 0.76 opacity to get a protected background of #454948, and checks each requested colour against it. The pure-white reference and the default white headline colour used in the figures below are inline literals in the renderer that it does not export; this page mirrors them by hand and does not check them against the renderer at build time, so if it ever samples the photo or changes that default, this paragraph must be updated to match. A colour at or above the overlay engine’s own default minimum ratio — which the engine documents as matching the WCAG AA text figure of 4.5:1 (verified 2026-10-02), a default this page reads from the function rather than checks against it — is kept; one below it is replaced by the engine’s dark ink or white, whichever contrasts more. The headline is requested in white by default (a design’s own title colour can be passed instead) and that default is kept at 9.13:1; the kicker is requested in the accent by default (a design’s own kicker colour can be passed instead), and a fictional mid-tone accent of #4a7c6f is replaced by #ffffff at 9.13:1. In the Tutorial template the resolved kicker colour fills the label box behind the kicker, and the kicker text itself is drawn in a fixed light tone the renderer keeps for that template. The thumbnail page tabulates more examples.

Background removal: 3 on-device tiers, sizes measured from the files

The Background Remover runs 3 segmentation tiers in the browser tab, with the model and runtime files self-hosted on this site. The first use of a tier fetches its model and runtime from this site, and after that the work happens locally — an engine is created once per tab and reused for every photo that follows. The download label each tier shows is computed from the real byte counts of those files, measured on disk when the site is built:

• Fast — people (auto): 11,734,025bytes, shown as “~11.7 MB on first use”.
• Click the subject: 17,712,372bytes, shown as “~17.7 MB on first use”.
• Best quality — any subject: 86,912,327bytes, shown as “~86.9 MB on first use”.

Labels use the SI megabyte that browser download dialogs use, so 20,971,520 bytes reads as 21.0 MB. Inputs are PNG, JPEG, or WebP (image/png, image/jpeg, image/webp) up to 20 MiB, which is 20,971,520 bytes exactly; a fictional team-photo.jpgone byte over it is refused with the engine’s own message, “team-photo.jpg is larger than the 20 MB limit.”, while a file exactly at the ceiling is accepted. Note that the refusal message labels the 20 MiB ceiling in megabytes as a round figure, a different rounding from the 21.0 MB SI label the download sizes above use; the engine is quoted as written. A cutout is named from the source: Team Photo (final).JPG downloads as team-photo-final-cutout.png. Model origins, versions and file hashes are documented in provenance files shipped beside the files.

The colour doctrine

Picked colours are honoured exactly. The Studio validates a colour for format only and never rewrites it: a title colour of #9a9a9a survives normalisation as #9a9a9a, even though it measures 2.73:1 against the default content background of #fbfcfa. Readability is surfaced as a live advisory against the 4.5:1 threshold, so you see a failing pairing before export — but the decision stays yours. The single exception is the thumbnail overlay text described above — the kicker and the title — protected at render time because it draws over photographs the design cannot predict.

The same doctrine applies to the QR tools: contrast is computed and reported, the classic maker warns, and only the artistic engine — whose decoration already spends the decode margin — refuses a failing pair outright.

The package

The Studio assembles its ZIP on the device. Alongside the graphics, QR files, card and captions it writes a manifest recording the destination, the design settings and the file list, stamped with design schema version 3 so a later reader knows which shape to expect, and a README that says where each file is posted. The package anatomy guide walks through the contents.

Platform figures and how they are verified

The tool pages and the guides type no platform figures of their own. Every platform size, aspect ratio, file limit and standards figure they quote is typed once, in a single registry, with the official page it was read from, the sentence it was read from and the date of the reading. Those pages read the registry; nothing is retyped on them, so a figure cannot be current on one guide and stale on another. A few engines, not only the registry, carry platform wording of their own: the Studio’s package builder writes a README into the ZIP that names the export sizes the Studio produces and the placements each file was designed for; the caption builder truncates the X variant to that platform’s character limit; and the thumbnail renderer can draw its duration and hover-control safe-area guides over the canvas. Each is written in the engine rather than read from the registry, so a change recorded in the registry does not rewrite it.

Each entry carries one of these statuses. Confirmed means the official documentation stated the figure the site already carried. Changedmeans the official text differs from the site’s earlier wording, in which case the registry carries the official figure and quotes the sentence it came from. No official sourcemeans no official page states the figure — it is a rule of thumb or an observation about how a platform renders — so the entry keeps the site’s August 2026 wording and date, and the guides that cite it keep the caveat to verify against the platform’s own documentation before a critical print run or launch. The registry currently holds 38 entries: 24 confirmed, 7 changed and 7 without an official source. The dated entries were read between 2026-10-02 and 2026-10-05.

How to read the table. A changedrow is not a correction the site made; it is the official page saying something different from what the site said in August 2026, recorded verbatim so you can compare. A row without an official source is not wrong; it is unsupported by a platform’s own documentation, which is a different thing, and that is why its “Read on” cell shows the month of the site’s earlier wording rather than a reading date. Guides that cite registry figures compute their “Verified” line from the latest date among those figures, so a guide that cites only undated rules of thumb still reads August 2026; guides whose facts are engine constants and build-time measurements carry the date they were read against the engine.

What the tools do not do

• Generating, converting, segmenting and downloading upload nothing: encoding, conversion, segmentation and packaging run in the browser, and the Studio’s package is assembled on the device. Saving a campaign or an artifact to an account is a separate, explicit action that sends the built package — never your source files — to the account’s library.
• They do not promise a scan. The QR engine computes contrast, forces error correction and caps the logo area because those are measurable; the guides still ask you to test-scan a printed proof on more than one phone.
• They do not rewrite your colours, except the thumbnail overlay kicker and title, and they do not clamp an over-cap logo request — they refuse it and say why.
• The tool pages and guides do not carry platform figures of their own. Every size, limit and ratio on them is read from one registry with its source and verification date, and figures without an official source keep their original August 2026 wording. A few engines carry platform wording of their own, as noted above — the package README’s export sizes and placements, the caption builder’s X-length limit and the thumbnail renderer’s safe-area guides — written in the engine rather than read from the registry.
• The QR maker does not rewrite a URL. A URL payload is validated — the protocol must be present — and encoded exactly as typed, so what the reader opens is the text you entered.
• They do not choose a platform’s thumbnail for you or report how a platform will show it. The thumbnail maker fetches the platform’s own candidate images in order and checks each one’s width; what a platform does with the export afterwards is outside the engine.
• They do not fetch a model or a runtime from a third party. The background remover’s files are served from this site, and their origins, versions and hashes are recorded in the provenance files shipped beside them.

The guides

Each guide applies one part of this page to a placement — a poster, a feed post, a thumbnail, a package — and every one of them links back here for the rule it relies on. All 12 are listed on the guides hub:

• Social media image sizes that actually fit (2026) — the Studio's social graphics and the specs registry.
• Promo design basics: hierarchy, contrast, and one idea — the colour doctrine and the contrast advisory.
• QR codes on promo materials: size, contrast, and placement — the quiet zone, error correction, contrast and print-size rules.
• YouTube thumbnail specs and legibility — the thumbnail canvas and the protected overlay text.
• Event promotion checklist: from announcement to day-of — the calendar payload and the package's event files.
• Anatomy of a complete promo package — the package manifest, README and file list.
• How the QR maker encodes ten payload types — the payload builders and their escaping rules.
• Logo and photo QR codes and the decode margin — the logo area cap, EC-H and the halftone limits.
• Verified barcodes for promo materials — verify-or-compute and the cross-check.
• Favicon packages explained — the rendered icon set, the ICO and the manifest.
• Local image conversion explained — signature detection, output naming and the converter's notes.
• On-device background removal — the 3 tiers and their measured download sizes.

Review record

The most recent reading recorded in the registry is dated 2026-10-05.

A review of this page means three things: the engine constants and functions it imports still exist under the same names, so the page still builds; the fixed example inputs still produce the strings and errors the prose describes, which the module-scope checks enforce by failing the build otherwise; and the specs registry was re-read against its official pages, with any difference recorded as a changed entry rather than edited into the prose. The verification date shown at the top of this page is the latest date in the registry, not the date of the review.

Questions

Why does a centre logo force error-correction level H?

A logo knockout destroys modules that error correction must reconstruct, so the engine does not leave the level to the user: the fictional destination https://example.com/launch encodes at level M on its own and at level H with a logo, with ecForcedByLogo set to true. The artistic styles require level H for the same reason.

Why is a 20% logo request refused instead of shrunk to the cap?

The cap of 16% is a measured decode margin, and a request above it is rejected rather than clamped so the caller learns the code would be unreliable. The fictional 20% request returns: "A logo may cover at most 16% of the symbol area — above that, the code stops decoding even on a clean scan." The default request is 12%, held below the cap for print and scan headroom.

Why do the thumbnail overlay kicker and title change colour when the Studio never rewrites colours?

The overlay text — the kicker and the title — is drawn over a photo the design cannot predict, so the renderer assumes a white background, composites its scrim at 0.76 opacity to a protected background of #454948, and replaces a colour that falls below the engine's minimum ratio with its dark ink or white. The default white headline is kept at 9.13:1; a fictional mid-tone kicker accent of #4a7c6f is replaced by #ffffff. Everywhere else a picked colour survives normalisation exactly, with contrast shown as an advisory.

Where do the platform figures on the guides come from?

From one registry of 38 entries, each with its official source URL, the sentence it was read from and the reading date: 24 confirmed, 7 changed and 7 without an official source. The dated entries were read between 2026-10-02 and 2026-10-05; the undated ones keep the site's earlier wording and are marked as such in the table above.