A QR code scans fine even when the data inside it is wrong. That is the uncomfortable part of building anything that generates codes from user input: a malformed URL, a phone number missing a digit, or an email address with a typo will still produce a perfectly scannable code, it just sends whoever scans it somewhere broken. Catching that before the code gets generated, printed, or published is where a little regex validation earns its keep.
Why Validate Before You Encode
Once a QR code is printed on packaging or a poster, fixing bad data means reprinting. Once it is published on a page, fixing it means someone has to notice the complaint first. Validating the input before the code is ever generated is the cheapest point in the whole process to catch a mistake, and it takes a fraction of a second compared to the cost of finding out later.
What Regex Is Good At, and What It Isn't
A regular expression is a pattern-matching tool, and it is genuinely good at checking structure: does this string look like a URL, does this look like an email address shape, does this phone number have the right number of digits in roughly the right places. What regex cannot do is confirm the URL actually resolves, the email address actually exists, or the phone number actually belongs to a working line. Structural validation catches typos and obvious mistakes. It is not a substitute for actually testing the destination.
A Practical URL Validation Pattern
For most use cases, a full RFC 3986 compliant URL pattern is overkill. A simpler pattern checking for a valid scheme, at minimum one dot in the domain, and no unescaped spaces catches the vast majority of real mistakes people make when hand-typing a URL into a form. The goal is catching "htps://example.com" or "example.com " with a trailing space, not building a parser that handles every edge case in the URL specification.
Photo by Markus Spiske on Pexels
Validating Emails and Phone Numbers for QR Payloads
The same logic applies to email and phone QR codes. An email pattern checking for a single @ symbol, no spaces, and a domain with at least one dot will catch most typos without needing to replicate the full email specification, which is notoriously more permissive than most people assume. For phone numbers, strip formatting characters first, then check digit count against the expected range for the country format you are targeting, since a QR code encoding a phone number with a missing digit will dial a completely different, wrong number.
Common Regex Mistakes That Let Bad Data Through
The most common mistake is writing a pattern that is too permissive, often because of a missing anchor at the start or end of the string, which lets extra characters slip past validation unnoticed. The second most common mistake is the opposite problem: a pattern so strict it rejects legitimate input, like international phone numbers or email addresses with plus-sign aliasing, frustrating real users over edge cases that were never actually wrong.
"Regex will catch the malformed input, but it won't catch the URL that's correctly formatted and just wrong. Validate structure with regex, then actually click the link before you commit to printing it anywhere." - Dennis Traina, founder of 137Foundry
Testing Your Pattern Before Using It in Production
Test any validation pattern against both valid and deliberately invalid examples before wiring it into a live form or generation workflow. Include edge cases you expect to see in practice: a URL with a query string, a phone number with parentheses and dashes, an email with a subdomain. A regular expression that only gets tested against the happy path will pass every demo and then fail on the first real-world input someone throws at it.
Building This Into a QR Generation Workflow
If you are generating QR codes programmatically, whether for a batch of product labels or a signup flow, validate the input the moment it is captured, before it ever reaches the code generation step. Reject or flag anything that fails the pattern, rather than silently generating a code from data you have not checked. This is a small amount of extra logic that prevents an entire batch of printed codes from pointing at broken destinations.
A Worked Example: Validating a Product Page URL
Say you're generating QR codes for product packaging, each one pointing to a product page built from a slug in your database. A reasonable pattern checks that the string starts with https, contains your domain, and has no whitespace or unescaped special characters in the path. Run every generated URL through that check before it goes into the code generation step, and log anything that fails rather than silently skipping it, since a silent skip on a packaging run means a batch of physical products missing a code entirely.
Validating in the Browser vs Validating on the Server
If you're capturing user input through a form before generating a code, client-side validation with the same regex pattern gives immediate feedback and catches obvious mistakes before submission. That said, client-side validation is a convenience layer, not a security boundary, since anyone can bypass it by calling your API directly. Always re-run the same validation server-side before the data reaches your QR generation logic, treating the client-side check as a UX improvement rather than the actual gate.
Logging What Fails Validation
Beyond rejecting bad input, keeping a simple log of what fails validation and why is worth the small amount of extra code. Patterns in failed validation, like a consistent typo in how users format phone numbers, tell you something about your input form or documentation that is worth fixing at the source, rather than just catching the same mistake over and over downstream.
Handling Internationalized Input Without Overcomplicating It
If your users span multiple countries, phone number and address formats vary enough that a single rigid regex pattern will reject a lot of legitimate input. Rather than trying to write one pattern that handles every country's format correctly, use a looser structural check, right number of digits within a broad range, presence of an expected prefix, and lean on a dedicated parsing library for anything where correctness genuinely matters, like billing or shipping. Regex is a good first filter, not the final word on international data.
Keeping the Pattern Maintainable
A validation pattern that works today can quietly become wrong as requirements change, a new top-level domain becomes common, a new country gets added to your user base, a new field format gets introduced. Comment your regex patterns with a short plain-language description of what they're checking and why, and revisit them periodically rather than treating a working pattern as permanently correct. Six months from now, neither you nor a teammate will remember the reasoning behind a dense regex string without that context written down somewhere nearby.
Where This Fits With QR Code Design
Validating the data is only half the reliability story. Even a perfectly valid URL can produce a QR code that fails to scan if the error correction level, contrast, or print size is wrong. EvvyTools' guide to building QR codes that actually scan covers that side of the process in detail. For testing your own validation patterns before you build them into anything, the Regex Tester runs your pattern against sample strings in the browser with no signup required.
Top comments (0)