How to svg qr code scanner compatibility: complete reference guide
- Step 1Confirm format is a non-issue — Stop worrying about SVG vs PNG for scanning. Whether you ship the SVG inline, print it, or rasterise it with /svg-tools/svg-canvas-exporter, the camera sees rendered pixels. Focus your testing on contrast, size, and quiet zone instead.
- Step 2Check contrast — Run the foreground/background colour pair through a contrast checker — aim for at least 3:1, foreground darker than background. The generator uses solid colours, so once it passes, it passes consistently; there's no gradient to vary mid-code.
- Step 3Verify module size at the camera — On screen, keep each module at least 2x2 CSS pixels and never display a code under ~150x150px. In print, ensure the code is large enough that single modules aren't smaller than the camera can resolve at the intended distance.
- Step 4Inspect the quiet zone — The tool bakes in a 2-module margin. If the code sits on textured or coloured artwork, add white padding in your layout so the boundary is unambiguous; scanners rely on that clear border.
- Step 5Test across multiple scanners — Try iOS native camera, Android (Google) native camera, a ZXing-based app, and a dedicated scanner app. They use different decoders with different tolerance for colour, damage, and inversion — a code that reads on all of them is safe.
- Step 6Test under real conditions — Scan the actual deliverable under the lighting and finish it will live in — sunlight, retail fluorescents, dim rooms. For print, matte beats glossy. Only sign off after the real artifact scans on more than one device.
What does and does not affect scanning
Separating real factors from non-factors so you test the right things.
| Factor | Affects scanning? | Why |
|---|---|---|
| File format (SVG vs PNG) | No | Scanners read rendered pixels, not the source |
| Contrast | Yes | Below ~3:1 the decoder can't separate modules |
| Module size at camera | Yes | Too small and the camera can't resolve squares |
| Quiet zone | Yes | Needed to detect the code boundary |
| Reversed colours | Yes | Many older apps can't read light-on-dark |
| Surface finish | Yes | Glossy glare overexposes modules |
Scanner support quick reference
General behaviour across common scanner types. Native cameras are the most capable; older third-party apps the least tolerant.
| Scanner | Dark-on-light | Reversed (light-on-dark) | Coloured codes |
|---|---|---|---|
| iOS native camera | Yes | Often yes | Yes if contrast holds |
| Android native (Google) | Yes | Often yes | Yes if contrast holds |
| ZXing-based apps | Yes | Sometimes | Yes if contrast holds |
| Older third-party apps | Yes | Frequently no | Risky at low contrast |
Module-size minimums
Keep modules above these thresholds so the camera resolves them at the intended distance.
| Context | Minimum per module | Practical rule |
|---|---|---|
| On-screen | ~2x2 CSS px | Never display under ~150x150px total |
| Print, arm's length | scannable at ~30–50 cm | 2 x 2 cm code minimum |
| Print, ~2 m | larger modules | 5 x 5 cm code or bigger |
| High-density (long data) | fails fastest when small | Shorten data to lower the version |
Cookbook
A reusable validation checklist plus the specific tests for the conditions that break codes. Run these against the actual deliverable, not just the on-screen preview.
Pre-publish scan checklist
The minimum gate before any code ships.
[ ] Contrast >= 3:1, foreground darker than background [ ] On-screen >= 150x150px; modules >= 2px [ ] Quiet zone intact (add padding on busy art) [ ] Scans on iOS camera + Android camera + 1 app [ ] Scans under target lighting (sun/retail/dim)
Contrast test for a brand-coloured code
Solid colours make this a one-time check.
Foreground #0b1f3a on Background #f2f6ff → contrast ~13:1 PASS Foreground #3a4a6a on Background #2a3550 → contrast ~1.6:1 FAIL (too close)
On-screen size check
Ensure modules survive a phone camera pointed at a display.
Code: version 3 (25 modules) + 2-module quiet zone each side = 29 Displayed at 290px → ~10px per module GOOD Displayed at 116px → ~4px per module RISKY Rule: don't render under ~150px
Reversed-code compatibility test
Decide if you can risk light-on-dark.
Foreground #ffffff on Background #101418 Test on: iOS camera (likely OK), older 3rd-party app (often fails) Verdict: keep dark-on-light unless you control the scanner
Glare / finish test for print
Catch the most common print failure before the run.
Print a proof at final size Scan under direct sunlight and bright retail light Glossy + glare = fail → switch to matte, enlarge, level H Retest until it reads from the intended distance
Edge cases and what actually happens
Assuming SVG scans differently from PNG
By designIt doesn't. Scanners read the rendered pixels; the source format is irrelevant. An SVG and a PNG at the same displayed size produce identical pixel data to the camera.
Low contrast colour pair
FailForeground and background too close in luminance (e.g. dark blue on navy) drops below the ~3:1 threshold and decoding fails. Pick a clearly darker foreground on a light background.
Code displayed too small on screen
FailUnder ~150x150px (or modules below ~2px) the camera can't resolve modules. Increase the displayed size; vector output enlarges without quality loss.
Quiet zone crowded by artwork
Scan riskThe 2-module margin is minimal, so a textured or coloured background bleeding into it confuses boundary detection. Add white padding around the code.
Reversed (light-on-dark) code
Scan riskNative cameras often manage it, but many older third-party apps can't. Use dark-on-light unless you fully control which scanner your audience uses.
Glossy print in bright light
FailSpecular glare overexposes modules in the camera sensor. Use matte finishes, larger codes, and level H for outdoor or glossy surfaces.
Very dense code from long data
Scan riskLong payloads create high-version codes with tiny modules that fail first when small or low-light. Shorten the data (use a redirect) to lower the version.
Expecting a logo or gradient to be present
Not supportedThe generator outputs only solid-colour modules and a background — no embedded logo, no gradient. A poorly composited logo or hand-added gradient is a common self-inflicted scan failure; keep coverage low and contrast high.
Quiet zone cropped to fit
FailTrimming the white border removes the boundary scanners require. The margin is already only 2 modules — never crop it; add space instead.
Frequently asked questions
Do scanner apps treat SVG QR codes differently from PNG?
No. Scanners read the rendered pixels from the camera, so the source format is irrelevant. An SVG rendered on screen or printed produces the same pixel data to the scanner as a PNG at the same size. Format matters for delivery, not scanning.
What contrast ratio does a QR code need?
At least 3:1 between foreground and background, with the foreground darker. The generator uses solid colours, so once a pair passes a contrast check it stays consistent across the whole code.
How small can a QR code be on screen?
Keep each module at least 2x2 CSS pixels and never display the whole code under about 150x150px. A version-3 code shown at 290px gives roughly 10px per module — comfortably scannable.
Can reversed (light-on-dark) QR codes be scanned?
Modern iOS and Android native cameras usually can, but many older third-party apps cannot. For maximum compatibility, use dark-on-light. Only use inverted codes where you control the scanning app.
Why does my code fail in bright sunlight?
Glossy surfaces create specular glare that overexposes parts of the code in the camera sensor. Use matte finishes, enlarge the code so modules tolerate glare better, and use error-correction level H outdoors.
Does colour reduce scanability?
Only if it reduces contrast. A dark brand colour on a light background scans fine; two similar tones do not. Keep the pair above 3:1 and the foreground clearly darker.
Is the quiet zone big enough?
The tool uses a 2-module margin, while the spec recommends 4. It works in practice, but on busy or coloured backgrounds add extra white padding in your layout so scanners can isolate the code.
What is the maximum scan distance?
Distance scales with module size. A 5x5cm code reads from roughly 30–40cm with a phone; for 1–2m (menu boards, posters) go to 15cm or larger. A rough rule: max distance in cm is about 6x the code width in cm.
Which scanners should I test with?
At minimum the iOS native camera, the Android (Google) native camera, a ZXing-based app, and a dedicated scanner app. They use different decoders, so passing all of them means broad compatibility.
Does a logo in the code affect scanning?
It can. The generator embeds no logo, so any logo you composite yourself reduces readable area. Use level H, keep coverage under about 30%, centre it, and retest across apps.
Does rasterising the SVG to PNG change scanning?
No, as long as you rasterise at a sufficient size. Use /svg-tools/svg-canvas-exporter at the resolution the destination needs; the resulting PNG scans the same as the SVG at that size.
What's the fastest way to validate a code before launch?
Run the pre-publish checklist: confirm 3:1 contrast, adequate module size, an intact quiet zone, and successful scans on at least two devices under the real lighting. Only then publish.
Privacy first
Every JAD SVG tool runs entirely in your browser using the DOM API and Canvas. Your SVG files never leave your device — verified by zero outbound network requests during processing.