Yes, the QR code scanner was changed in the latest update, but we’ve not had any reports of any issues.
I think the problem is the spanish “ñ”., and the QR generation tool
Can you be more precise - where is this Spanish accent character being used?
Are you able to share a QR code that isnt now scanning correctly? If so please send it via PM but do not post it here, since these QR codes typically contain passwords encoded in them.
Thanks. Can you tell me what specific tool was used to generate this QR code? Interestingly, I can generate a QR code with your exact same string - including the accented Ñ - but it results in a somewhat different code matrix, but one which the new KoboCollect QRCode widget can still scan without any problems.
This indicates its not simply the presence of the Ñ character in the string but something else that’s causing the (new) scanner to fail to recognize it. Hence what tool was used to create yours?
FWIW I’ve confirmed that yes this particular code was readable by the previous KoboCollect/ODK Collect v2025.2.3, but is no longer readable is in latest KoboCollect v2025.3.3. (it looks like it broke upstream in the QR code changes that went into ODK Collect v2025.3.0). I’ll continue investigating and probably raise a ticket.
It would still be good to understand what tool you are using to generate them; this might give a clue as to what specific QR code feature the new de-coder apparently isnt handling.
Thank you very much for the help and the time dedicated to solving this issue.
For the generation of QR codes, we use QR4OFFICE .
I believe this shows that the reading error, or the inability to read the “ñ” character, is due to a combination of an app update and the QR4OFFICE program.
In any case, the definitive solution is to stop using the “ñ” character in QR encoding, just as it should not be used in databases either. It always causes problems.
Thanks. I’ve run a few experiments and from what I can tell, QR codes generated by this tool which contain almost any accented characters - eg Ñ, å, Å - will fail to be scanned by the new Collect QR-decoder. But they scan fine in the previous version (!?). FWIW changing the error correction levels in the QR codes made no difference - anything from QR4OFFICE with an accented char now fails.
I’ll report the issue, but I suspect QR4OFFICE is doing something ‘quirky’ in how it goes about encoding accented (ie unicode) characters, which the new decoder is apparently sensitive to.
As you suggest, you could choose to avoid accent chars in the string your are encoding altogether, or alternatively use a different QR code generator. For example, this one will encode your Ñ in a manner that the new QR decode in KoboCollect handles fine.
Thank you so much for your dedication. With the problem identified, it's relatively easy to find a solution: avoid using "unusual" characters if we want to continue using QR4OFFICE, or change the QR code generator, as you suggest. Fortunately, and following the logic of the databases, we have very few QR codes generated with "ñ" or '. Thanks again for your excellent work.