The QR Code Generator's March Predictions All Came True

Back in March I wrote that "encode a URL" was an obviously incomplete answer to what a QR generator should do, and that I could already tell this tool would be one of the more actively developed ones on the site. Today it grew from one encoding type into eight — URL, plain text, WiFi credentials, vCard contact cards, email, SMS, phone numbers, and GPS location — plus logo overlay support and a proper multi-step interface to hold all of it.

Eight data formats meant eight different payload structures inside one QR standard

The underlying QR encoding itself doesn't change between types — what changes is the structured data getting encoded into it. A WiFi QR code needs a specific formatted string a phone's camera knows to interpret as network credentials; a vCard needs its own standardized contact-card format; an SMS code needs the phone number and message packed together in a way a messaging app recognizes. Each type meant building and correctly formatting its own payload structure, then verifying real devices actually interpret it the way the standard intends, rather than just trusting that a technically valid-looking string will scan correctly on every phone's camera app.

A single text field couldn't hold eight types, so the interface needed real structure

March's version was one text field and nothing else. Eight types with genuinely different required fields — an SSID and password for WiFi, a name and phone and email for a vCard, latitude and longitude for a location — meant the interface itself needed real structure: pick a type, fill in that type's specific fields, then customize. That's why today's version organizes into an explicit multi-step flow rather than trying to cram every possible field for every possible type onto one increasingly cluttered form. Type selection has to happen first and change what the rest of the interface even shows, which is a meaningfully different interaction model than the single always-visible field the original version got away with.

Logo overlay meant finally needing the error-correction levels I mentioned holding off on

I wrote back in March that error-correction levels weren't exposed yet because there wasn't a real reason for someone to want that control, and predicted logo overlay would eventually be exactly that reason. It was. Placing a logo in the middle of a QR code covers real encoded data, and the code only keeps scanning correctly if enough error-correction redundancy is built in to recover from that covered region. Exposing error-correction levels — and specifically recommending the highest one whenever a logo is added — was the direct, predictable consequence of finally building the feature that needed it, exactly like I'd expected it would be when I first wrote that note down.

Type-specific validation had to catch mistakes before generating a broken code

Each new type comes with its own required fields, and generating a code from an incomplete or malformed set of inputs — a WiFi entry missing a password, a phone number with invalid characters — would produce a technically-rendered QR code that scans to something broken or nonsensical rather than failing loudly and obviously. I built real per-type validation that catches these problems before generation rather than after, since a QR code that renders but scans to garbage is a much more confusing failure for someone to debug than a clear, immediate message explaining exactly which field still needs attention before a code can be generated at all.

Backward compatibility meant the original URL flow couldn't feel demoted

URL encoding is still almost certainly the most common reason anyone opens this tool, and I didn't want someone who just wants a quick URL code to suddenly need to navigate a more complex multi-type interface to get there. URL stayed the default selected type, reachable in exactly as few steps as the March version required, with the other seven types available as a deliberate choice rather than the first thing anyone has to wade through. Growing a tool's capability shouldn't tax the use case that was already working well before the expansion happened.

Every new type needed the same real-scan discipline from March

Back in March, I wrote about the importance of actually scanning generated codes with a real phone camera rather than trusting that correct-looking output meant correct-scanning output. That discipline mattered even more this time, across eight types instead of one — a WiFi code that encodes technically valid data but uses a formatting quirk a specific phone's camera doesn't parse correctly is a much subtler failure than a broken URL code, since the QR code itself still looks completely normal and even scans as *something*, just not the network-join prompt it's supposed to trigger. I tested every new type against multiple real devices specifically because "looks right" and "scans right" turned out to diverge more easily across eight formats than it ever did for one.

The March post basically predicted today, and that's worth noting

Reading back my own launch post before writing this one, nearly every guess I made about what this tool would eventually need — WiFi credentials, contact cards, a reason to finally expose error-correction levels — turned out accurate. I don't think that's because I'm especially good at predicting my own roadmap. It's because the gaps were genuinely obvious the day I shipped a deliberately minimal first version, and writing them down in March meant today's expansion was executing a plan rather than improvising one from scratch.

I don't think every tool deserves a devlog post quite this reflective about its own past predictions, but this one earned it — the March post wasn't just documentation after the fact, it turned out to be a real roadmap I ended up following months later, almost point for point, down to the exact reason error-correction levels finally needed exposing once a logo actually needed room to sit in the middle of a real code.