Your logo in the middle of every QR code
A logo in the middle of a QR code looks like a cosmetic decision. It is also the one change that can quietly stop the code from scanning, and the failure surfaces months later on a printed card in somebody's wallet, long after the preview looked fine. Every QR code ScaanMe produces now carries a mark in the centre, and most of the work went into making that safe.
What changed, and where you see it
Every QR code the platform produces renders through one shared server-side path: the code on a digital business card, the code on a store page, the per-table codes behind a QR menu, and the printed QR sheet you hand to your sign maker. Every tool and every theme goes through it.
By default the mark is the ScaanMe mark, two cyan parallelograms forming an S. On Pro Max, the vCard plans, and Prime, the store plans, it is your own uploaded logo instead. The entitlement is a per-plan flag an admin sets, called qr_custom_logo, switched on for every Pro Max and Prime row. Lite, Pro, Starter and Advance carry the ScaanMe mark, so a free QR menu puts it on every table code. Which tier sits where is on the pricing page.
Screen and print use SVG, so the code stays sharp on a business card or a shopfront decal. Downloads come out as PNG.
Why a mark in the middle scans at all
A QR code is your link encoded into black and white modules, plus a block of redundancy computed from it and spread across the symbol. Error correction lets a scanner rebuild the payload when part of the code is unreadable.
Every ScaanMe code renders at level H, the highest of the four levels the standard defines. Level H carries enough redundancy to recover roughly 30% of the codewords, so about a third of the code can be unreadable and the payload still comes back. That budget is the only reason a centre mark is possible. The scanner treats your logo as damage and repairs it from the copy of the payload spread across everything else.
Which is where the honest part starts. Every module your mark covers is redundancy already spent, and no longer there to absorb a crease, glare off a shop window, or a scan at a bad angle.
The size ceiling, and what it is a share of
The mark plate renders at 21.2% of the symbol, and the renderer refuses any ratio above 25%, throwing instead of drawing. Both numbers came out of measurement. Read them as fractions of the symbol's side, the way you read the width of a stripe across a square, not as shares of its area.
| Share of the symbol's side | What it is |
|---|---|
| 21.2% | the knockout plate that renders on every code today |
| 25% | the ceiling the renderer will not cross |
| 40% | refused before anything is drawn |
A mark at 40% still decodes while the print is pristine, which is the trap. It looks fine right up until the card is real: printed, handled, folded once, scanned at an angle under bad light, with no redundancy left to spend. ScaanMe's test suite asserts that 40% throws, so it never reaches a page. At the rendered 21.2% the code measures the same as one carrying no mark.
The knockout plate under the mark
The mark sits on a knockout plate, a rounded square punched out of the modules beneath it, with the artwork inset so it never touches the edge.
The plate exists because the ScaanMe mark is two separate parallelograms with a gap between them. Dropped straight onto the symbol, dark modules show through that gap, the shapes stop reading as one object, and what you get is a smudge rather than a logo. The plate gives the mark a clean field, which is why the plate and the artwork are quoted as two different sizes: the plate is the cleared area, the mark sits inside it with a margin.
What happens when you upload your own mark
This is the part that matters if you are on Pro Max or Prime. The upload lives in the card editor. The file is checked first: a real raster image, 2 MB or smaller, at least 256 by 256 pixels so it stays clean when scaled down, and roughly square, within 2:1 either way, so it does not letterbox inside the plate.
Size is not left to you: whatever you upload lands on the same plate at the same 21.2%, costing the code the same modules every time, and no field lets you push it past what level H can carry.
Module colour is fixed in the renderer rather than left to you, dark navy on white with a four-module quiet zone, and measured for contrast against WCAG relative luminance with a 3:1 floor before any code is drawn. The rule the code follows is worth repeating: brand cyan is a mark colour, never a module colour.
The details that keep printed codes working
Three smaller decisions do most of the work, and none are visible to the person scanning.
The encoded payload uses the card's internal id rather than its URL slug, so you can rename your card and every code you have already printed keeps resolving. That is the principle behind a dynamic QR code: what gets printed points at something stable, and what it opens stays editable.
The rendered SVG is cached for a day, so a page showing the same code does not redraw it on every request.
A build guard fails CI if a new surface builds a QR code outside the shared renderer, which stops this drifting back into per-theme copies with no ceiling on them. The SVG also carries role="img" and an aria-label, so a screen reader announces the code instead of skipping past it.
What a mark does not do, and what to check yourself
A mark does not improve scanning: it spends redundancy that would otherwise absorb print damage, dirt, glare and bad angles.
The renderer enforces the size ceiling and the colour contrast, with the mark held well under the level H budget and the knockout plate keeping the shape readable. What it does not do is render your uploaded logo and read it back before saving it. So scan your printed proof, at the distance and angle your customers will use, before you commit to a print run. Simple, high-contrast, roughly square marks survive that test, while thin strokes, gradients and photographs turn into noise once the symbol is a few centimetres wide.
A printed code is one way in among several. A camera reads it from across a room, while an NFC tap needs the very short range the NFC Forum describes, and the smartphone reach that makes either worth printing is tracked each year in DataReportal's Digital 2026 report for Jordan. Our comparison of NFC against QR codes covers placement, and what a QR menu is is the short version for restaurants.
Frequently Asked Questions
Do I get my own logo in my QR code, or the ScaanMe one? By default that mark is the ScaanMe one, on every plan. Your own logo is an entitlement on Pro Max for vCard plans and Prime for store plans, set as a per-plan admin flag called qr_custom_logo. Lite, Pro, Starter and Advance carry the ScaanMe mark.
Does putting a logo in the middle make my code harder to scan? It does not help, and that is the honest answer. A mark spends redundancy that would otherwise absorb print damage, dirt, glare and bad scanning angles, which is why the plate is held at 21.2% of the symbol's side and the renderer refuses anything above 25%. At that size the code reads the same as one carrying no mark.
How large can my logo get? You do not control that. The plate is a fixed 21.2% of the symbol's side whatever you upload, and a ratio above 25% throws rather than producing a code. A mark at 40% is refused on that basis, and the test suite asserts it.
Does ScaanMe check that my uploaded logo still scans? Not at save time, so treat your printed proof as the check. The file is validated for format, weight, pixel dimensions and shape, and the mark is then held at a fixed width well under what level H can absorb. Scanning the printed card before a print run is the step worth taking.
If I rename my card, do the QR codes I already printed stop working? No. The encoded payload uses the card's internal id rather than its URL slug, so the printed symbol points at something that does not change when you rename the card, edit the address people see, or redesign the page behind it.
