What you are seeing
The code scans, the form opens, but the fields that should be prefilled are empty: no name, no reference, no answers carried over from the code. The scan worked, so the fault sits in the handover between the code and the form: the payload, the link parameters, or the form itself. Visitors who expected a ready-filled form meet a blank one and must start over, which is exactly the friction the code was meant to remove. The fix is to trace the handover and to find where the values get lost.
Likely causes
1.
Link parameters missing or mistyped — A prefill that depends on link parameters fails when a parameter name is mistyped, missing, or encoded wrongly. Test: decode the payload and compare the parameters with the form field names.
2.
Form does not accept prefill — A form that was never set up to accept prefilled values ignores the parameters the code sends. Test: open the form with the parameters typed manually in the address bar.
3.
Redirect drops the parameters — A redirect can strip the parameters from the address, so the form receives a bare link with no values. Test: follow the redirect chain and watch the parameters.
4.
Field names changed — A form whose field names changed after the code was printed no longer matches the parameters the code sends. Test: compare the current field names with the parameters in the code.
5.
Values contain characters that break the link — Special characters in a prefilled value can break the link if they are not encoded correctly. Test: try a simple value with plain characters and compare.
Step-by-step fix
1. Decode the payload and write down the exact link and parameters it carries.
2. Compare the parameter names with the current form field names.
3. Open the form with the parameters typed manually and check whether they fill.
4. Follow the redirect chain and check that it preserves the parameters.
5. Fix the link, the redirect, or the form, whichever drops the values.
6. Retest by scanning the code and confirming every expected field arrives filled.
Putting this into practice
In practice, the manual-parameter test splits this problem in two. If typing the parameters into the address bar fills the form, the code or the redirect is at fault. If it does not fill the form, the form setup is at fault. That test tells you which side to fix. Keep a short note of what you tested, what failed, and what you changed, so the next person starts from evidence rather than guesswork. A fix that is written down survives staff changes and reprints; a fix that lives only in memory gets repeated.
Common mistakes to avoid
- Regenerating the QR code when the form itself was never set up to accept prefilled values.
- Reprinting the full run before a single proof passes, which turns one failure into many.
- Testing on one phone in ideal conditions instead of two phones in the real conditions where a code that scans but the form is empty will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that scans but the form is empty.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The parameter names match the current form field names
- Redirects preserve the parameters
- Scanning the code fills every expected field
- The corrected proof passes on two phones in the real conditions
- The fix is recorded in the job file so the next reprint starts from a proven setup
- Every printed copy is checked against the approved proof
- The proof is retested after any later change to the link, design, or placement
Related tools and guides
- [survey QR code generator](/survey-qr-code-generator)
- [feedback QR code generator](/feedback-qr-code-generator)
- [QR payload inspector](/qr-payload-inspector)
- [QR redirect chain viewer](/qr-redirect-chain-viewer)
- [QR expiry checker](/qr-expiry-checker)
- [UTM builder](/utm-builder)
