Your 3D printed QR code will not scan: nine causes and their fixes

By Tiehl Roberto Matías · 8 min read · Updated 25 October 2026

Leer en español

The piece came out well, the code looks perfect and the phone does nothing. Before you throw it away, this list runs from the most likely cause to the rarest, and each item carries the check that rules it out in under a minute.

1. The modules are too small

This is the cause in most cases. Each little square of the code has to be at least twice your nozzle: 0.8 mm with a 0.4 mm nozzle. Below that the printer cannot form squares with straight edges, it rounds the corners and ends up joining modules that should be separate.

How to check: look at the piece close up, with light coming from the side. If the lone modules — the ones that should sit isolated in the middle of a light area — appear joined to their neighbours by a bridge of material, this is it. To find out whether the size you used was enough, put your link into the calculator (in Spanish): it gives you the minimum for your nozzle.

If this happens to you often, it is worth measuring your printer's real limit once with the test kit (in Spanish): six identical pieces with different module sizes, and the smallest one that scans is your number.

Fix: make the piece bigger, or shorten the link to drop a version, which makes the modules larger without changing the size. The full calculation is in the minimum size guide. And if the modules are small, switch them to squares: below 1.25 mm the rounding the generator offers is too small to see and instead multiplies the stringing, as the module shapes guide (in Spanish) measures.

2. There is no quiet zone around it

The standard requires a plain band four modules wide on each side of the code. It is called the quiet zone and it is what tells the reader where the code ends. Without it the algorithm cannot find the edges and fails even if everything else is perfect.

How to check: measure the plain edge between the last module and the edge of the piece, or the text, or the ring hole. It has to be at least four times the side of a module. With 0.8 mm modules, that is 3.2 mm.

Fix: remake the piece with a quiet zone. There is no fixing it on a printed piece.

3. The first layer has fattened the modules

If the nozzle prints too close to the bed, the first layer squashes and spreads: that is elephant foot. On an ordinary piece you do not notice; on a QR code, each module grows a few tenths on all four sides and the light corridors between them close up.

The characteristic symptom is that the code reads well looking straight at it up close, but fails as you move away: the grid is there, but with the proportions altered.

How to check: look at the piece edge-on, against the light. If the first layer sticks out past the rest forming a small step, this is it.

Fix: turn on elephant foot compensation in your slicer (0.1 or 0.2 mm is usual) or raise the z-offset by two or three hundredths. And calibrate the first layer.

Before any of that, look at how the piece is sitting, because this cause depends on it. Elephant foot only deforms the layer touching the bed, and the way the file comes out of the generator that layer is the base: the code is fifteen layers higher up and never gets it. If you printed face up and the modules come out fat, the culprit is flow. If you turned it over so the code sits against the plate, then it is this, and the full account is in the guide to the two orientations (in Spanish).

4. The two colours do not contrast enough

The reader turns the image to greyscale before doing anything. Two colours that look very different can end up the same grey: red on black is the classic example, and it does not read.

How to check: take a photo of the piece and turn it black and white in your phone's gallery. If the grid is hard to make out in that photo, you have your answer.

Fix: light base, dark code. The combinations that work are in the filament colours guide. And if you do not have a second filament, the way out is not a single-colour code in relief but one engraved into the surface (in Spanish), which at least leaves the modules dark.

5. The filament is shiny

Silk, glitter and metallic filaments bounce light back like a mirror. Depending on the angle, a white reflection appears over the code which the reader takes for a light area, and half the grid disappears exactly when you bring the phone close, because its screen lights the piece up.

How to check: try scanning in the shade, away from any lamp and out of direct light. If it suddenly reads, the problem is glare.

Fix: reprint in matte filament, at least the code part. No slicer setting fixes this.

6. The relief is too tall

Above 1.5 mm the relief starts casting its own shadow onto the light modules next to it when light arrives from the side. The reader takes that shadow for dark material, and the grid it perceives stops matching the real one.

How to check: scan under very diffuse, frontal light, for instance near a window on an overcast day. If it reads that way and not under the ceiling spotlight, it is the shadow.

Fix: 0.8 to 1.2 mm of relief on plates and stands, and 0.6 mm on keychains and tags. The ceiling is not fixed: it depends on module size, and the calculation is in the relief height guide (in Spanish).

7. There is a mistake in the link

The code can be flawless and carry an address that does not exist. Watch out for these, which are more common than they sound:

• A space before or after the address when pasting it.
• The https:// is missing and the reader opens a search instead of the page.
• The address was temporary — a preview, a session link — and has expired.
• It is an internal link from a tool that only works while you are signed in.

How to check: scan the preview on screen. If the phone recognises the code but opens something odd or errors out, the code is fine and the link is not.

8. The correction level was too high for the size

It sounds backwards, and it happens: going up to level H so the code «holds up better» forces a larger version, and that version packs more modules into the same space, so each one gets smaller. You end up with a code that is theoretically more robust but worse printed.

How to check: generate the same link at level M and compare the module count. If it drops a version, this was your problem.

Fix: level M unless the code has a logo on it or is going to get dirty.

9. The centre logo covers too much

A logo or an emoji in the centre covers real modules. Error correction compensates up to a point, but it has a limit, and that limit is lower than the nominal percentage of the level, because part of the redundancy is already spent correcting the ordinary noise of printing.

Rule of thumb: the logo should take up no more than 20 % of the width of the code at level H, and no more than 10 % at level M. And always centred: the corners hold the position patterns, which cannot be covered at all.

Fix: shrink the logo, or raise the correction level and make the piece bigger in exchange.

If you got this far and it still will not read

Two more things to rule out, both rare:

• The scanning app. The native camera on some older phones is fairly bad at detecting codes. Try another phone before writing the piece off.
• The screw holding it up. If the plate reads in your hand and stops reading on the wall, look at the screw head: it is dark, it is wider than the hole, and it sits inside the code's plain margin. It is measured in the guide to hanging the plate (in Spanish).
• The surface it is resting on. A code on glass or on a very polished table picks up reflections from underneath. Try the piece on a dark cloth.
• The piece is not flat. If the code sits on a mug, a jar or a large plate that warped as it cooled, the curve distorts the grid. The limit is a specific number and it is in the curved surfaces guide (in Spanish).

And for the next piece: nearly all of these causes can be ruled out before printing, on screen and in the slicer's layer view. The order worth doing it in is in the testing guide (in Spanish).