A packaging comp needs a code in the bottom corner. The landing page will not exist for three weeks, the client has not decided what it says, and the layout is due tomorrow. So the designer pulls a code-shaped image off a stock library, drops it in, and sends the file for approval. It gets approved, goes to prepress, and runs on twelve thousand cartons, every one of them pointing at a URL belonging to a stranger.
Nobody was careless. The placeholder did its job, which was to look finished, and that is exactly the property that made it dangerous.
There is no such thing as a blank QR code
A QR symbol is the encoding of a string. The corner squares, the timing lines and the format bits are structure, so you can certainly draw something with all of those in place, and a reader will find it. It will then read the data region and get nothing usable out of it.
That leaves only two categories of object you can put in a layout. Either it is a real code that decodes to something, or it is a picture that is not a code. There is no third option, and "empty" is not one of them. Knowing which of the two you have in the file at any given moment is the whole discipline here.
The three things designers reach for
A stock code image, or one screenshotted out of somebody else's design, is a real code pointing at whoever made it. Cheap in the comp and expensive in the print run, and the failure is silent: the code scans, so every proofing stage passes it. This is the placeholder that reaches production most often, precisely because it looks the most finished.
A drawn or generated grid of squares points nowhere, which sounds safer and introduces a different problem. At comp size it is indistinguishable from the real thing, so it gets approved, and unless somebody put "replace the fake code" on a checklist, there is no moment in the process where it is supposed to be caught. It also makes the layout decisions on false evidence. A fake grid can be any density you like, so it tells you nothing about whether the real symbol will fit the space it was drawn into.
An empty square, or a square with a diagonal cross and the word CODE in it, is the honest one. Nobody mistakes it for finished art, which makes it right for an early layout and wrong the moment the layout has to be judged, because it does not occupy the space a real symbol occupies.
The right placeholder is a real code pointing somewhere you control
Generate a code now, pointing at a URL you own. A holding page, a "coming soon" path on the client's domain, the client's homepage if nothing better exists yet. Four things follow from that, and they are why this is the answer.
It decodes, so the file is testable at every stage rather than only after the real destination exists. It has the right density, so the layout is being judged against the symbol that will actually ship. If it reaches production by accident, it lands somewhere harmless belonging to the right party, and can be redirected rather than recalled. And proofing works the way it is supposed to, because anybody can scan the printed proof and see where it goes.
The density point deserves its own sentence, because it is the one people skip. A symbol's module count comes from the length of the string inside it, so build the placeholder from a string roughly the same length as the real one. A placeholder made from a twenty-character domain and a live code carrying a ninety-character tracking URL are different objects at the same printed size. The version ladder sets out how quickly that grows.
This is the argument for an editable destination
The workflow above only works cleanly if the destination can change after the symbol is fixed. That is precisely what a redirect-backed code provides: the printed pattern is final at artwork stage, and what it points at is decided later, or changed next year. Every code QRolling makes is dynamic, and the destination stays editable on the paid plan, which is what turns a placeholder into a first version rather than a thing to be replaced.
The static case is worth spelling out because it is the trap. A hard-coded URL from any tool freezes the placeholder address in the pattern permanently. If that is the route, the placeholder must be a path on a domain the client controls, so a server-side redirect can point it at the real page later. The full set of options, and how few of them exist once the print is out, runs through changing a printed destination without reprinting, and the general decision sits in static against dynamic.
What a designer does before the client has bought anything
This is the real question, and it has a straight answer rather than a clever one.
Use a path on the client's own domain as the placeholder destination, and have their web person add a redirect when the real page exists. Costs nothing, the client owns the endpoint, and the arrangement survives the project ending.
Use a path on your own domain during the design phase if you must, but do not let that version go to press. A code on packaging pointing at a designer's holding page is a dependency the client never agreed to, and it outlives the invoice by years.
Whichever you choose, put one line in the artwork handover naming the code's current destination, who is responsible for changing it, and by when. The note is the part that actually prevents the failure; the placeholder choice only decides how bad the failure is.
And settle one thing before the pattern is final: if the plan is a redirect-backed code, the string in the symbol is that service's short URL, and it cannot be swapped for a different provider's later without a new symbol and a new print run. Deciding the platform is part of finishing the artwork, not part of the launch.
The check that catches a fake before the press does
Run this on every job with a code in it, at the point the package leaves the studio.
- Decode every code in the file, from the exported PDF rather than the working file, with a reader that shows you the string before it opens anything. Read the string.
- List every code in the job with its current destination and a named owner, in the handover document.
- Never give the comp asset and the production asset the same filename.
- On press proofs, scan the printed code, not the artwork it came from.
- Search the package for any code asset that did not come out of your own generator. If you cannot account for where an image came from, it does not ship.
Two of those steps are about paperwork rather than design, which is why they get dropped. They are also the two that work. A wider version of the same exercise, run across codes that are already in the world, is in auditing codes for dead destinations; the placement of a code you did not make is the same problem as the stranger's stickers in fake and tampered codes, arriving from your own file instead of from a passer-by.
Generate the placeholder on the day you start the layout, not the day before the deadline. It takes two minutes, and it converts the riskiest object in the file into the finished one.
