Upload the document, print the code, hand out nothing else
You have a two page price list, a set of care instructions or a floor plan, and you are tired of photocopying it. Upload the file here and you get a square that opens it on any phone. The document sits on our server, the code points at it, and nobody has to type an address.
A document cannot live inside a QR code, and no PDF QR code generator anywhere works around that. There is room for about 4296 characters in the densest version, and a modest PDF is a few hundred thousand times bigger than that. So the code holds a web address. You upload the file, it is saved on free-qr.com under /uploads/ with a generated name, and the code encodes the link to that copy.
After a scan the phone shows the address and waits for a tap. iPhones have done this from the Camera app since iOS 11, Android since version 9, and older Android handsets manage it through Google Lens. The tap opens the browser, the browser fetches the file and renders it. Safari uses its own viewer, most Android phones pass it to Chrome or to Drive, and from there the reader can save or forward it. Nothing is installed and no one signs in.
The useful side effect is that the payload stays short. A link of forty odd characters gives a sparse code with fat modules, which is the version that survives a cheap print run. A code carrying the same information as raw text would be dense and far less forgiving.
The quiet zone is the usual culprit. Four modules of clear margin on every side, and a designer who crops to the black edge has made a dead code. Size is the second one. Divide the reading distance by ten: a code on a poster read from two metres wants roughly twenty centimetres a side, a code on a leaflet read at arm's length can drop to two or three. Below two centimetres nothing reliable happens.
Keep the code dark on a light ground. Inverted codes read fine on a new phone and fail on the scanner bolted to a warehouse wall. If you drop a logo in the middle, move error correction to Q or H, which is what pays for the covered modules. Q is already selected when the page loads.
What the code cannot do is tell you anything afterwards. A static code has no counter, so you will never know whether the forty leaflets in the waiting room were scanned twice or four hundred times.
The upload limit here is 10 MB. A forty megabyte scanned brochure will be refused, and the fix is to compress it first, which on a scan of printed pages usually means dropping the images to 150 dpi and re-exporting. That alone often takes a file under the limit without any visible loss.
Then consider the screen. The file opens in a phone browser, so a document laid out for A4 arrives as a full page shrunk to a six inch display. Body text at 10 pt becomes unreadable until the reader pinches and pans, which most will not bother doing. A two column datasheet is worse, because the eye has to travel up and back down the page on every column. Re-export it as a single column at a larger point size before you put a code on it. It is ten minutes of work and it decides whether the thing gets read.
One more thing to plan for. Replacing the file later gives you a new URL, and a new URL means a new code, so the two hundred cards you already printed still point at the old version. If the document will change, build the sign around an editable code from the dynamic URL page and repoint it when the price list moves. If you are printing in volume, the printing checklist covers the rest.
Ten megabytes. The upload checks the real type of the file as well as the size, so a renamed Word document will be turned away. If your scan is larger, re-export it with the images at 150 dpi, which usually brings a bulky brochure comfortably under the limit.
On free-qr.com, in the uploads folder, under a generated file name. The code points at that copy. Anyone who scans the code, or who is sent the address, can open it, so treat it as a public document rather than a private one.
Not with a normal code. A new upload gets a new address, and a new address needs a new code. If the document will be revised, make an editable code on the dynamic URL page instead and change where it points whenever the file changes.
No. The camera on an iPhone has read these since iOS 11 and Android since version 9. Older Android phones do it through Google Lens. The PDF then opens in whatever browser or viewer the phone already uses.
Take the distance it will be read from and divide by ten. A label read at arm span needs roughly two to three centimetres a side, a poster read across a room needs twenty or more. Under two centimetres the scan becomes unreliable.
Not with a code made here in the normal way. Static codes carry no counter and never phone home. Counting scans is only possible with the editable codes, which live on a separate page and need the short account the site creates for you.