QR Code Generator: Just a URL, at First

This is the first web tool on the site, and it does exactly one thing: you paste a URL, and it renders a QR code you can download as a PNG. There's no WiFi encoding, no contact-card format, no logo overlay, none of the extra encoding types I can already picture wanting to add later. Just a text field and a downloadable image. I'm writing that down explicitly because I already know this tool is going to grow, and I want a clean record of how small "a QR code generator" can actually be before it does.

Why a tool, and why this one first

Everything I've built up to this point has been a game. A QR generator is a different kind of thing entirely — no score, no win condition, just a small utility that does a job and gets out of your way. I picked this one to be first specifically because it's about as low-risk as a utility gets: the underlying QR encoding algorithm is a solved, well-documented standard, so I wasn't inventing anything technically novel. What I was actually testing was whether a non-game tool belongs on this site at all, and whether I could build one end-to-end, from a real need to a working page, without the scope creeping past what a person actually needs to put a scannable code on a flyer.

No account, no server-side generation, no logging

The code you're encoding never leaves the browser. There's no server round-trip that generates the QR image and hands it back to you — the whole encoding process runs client-side, which means I'm not logging what anyone's putting into their QR codes, intentionally or otherwise. That mattered to me more than it might sound like it should. A URL is usually harmless to see pass through a server log, but WiFi passwords and personal contact details are exactly the kind of thing this tool will eventually handle once more encoding types exist, and I'd rather build the "nothing ever touches my server" architecture in from day one than retrofit privacy onto a tool that started out logging requests by default.

The live preview mattered more than I expected

The QR code updates as you type, rather than waiting for you to click a "Generate" button. That was an easy technical choice — re-encoding on every keystroke isn't expensive for a plain URL — but it changed how the tool actually feels to use in a way I didn't fully predict. Watching the code visually reshape itself in real time as you finish typing a URL gives immediate, wordless confirmation that something's actually happening, which turns out to matter a lot for a tool that has zero other feedback. There's no progress bar, no loading state, nothing else on the page telling you the tool is doing its job. The live preview is effectively the entire UI.

Testing a QR code means actually scanning it

The thing I couldn't skip, no matter how confident I was in the encoding library doing the standard correctly, was pulling out my own phone and scanning the output. It's easy to trust that a rendered grid of black and white squares is correct because the code that generated it looks correct, and that's not the same as confirming a real camera in a real room with real lighting can actually decode it. I tested against a handful of different URL lengths specifically because QR codes get visually denser as the encoded data grows — a short URL produces a simple, chunky grid; a long one with tracking parameters tacked onto the end produces a much finer, harder-to-scan pattern at the same physical size. That's not something a browser preview tells you is a problem. A camera struggling to lock onto a busy grid absolutely does.

The QR standard has a few fixed error-correction levels built in, trading how much of the code can be damaged or obscured and still scan against how dense the resulting grid gets. This first version doesn't expose that as a setting — it just picks a reasonable default and moves on — but it's already on my list of things to surface later, once there's an actual reason for someone to want it, like sticking a logo in the middle of the code and needing extra redundancy to compensate for the part it covers.

Where I drew the line for this version

I thought about adding basic color customization — a colored foreground instead of plain black — before shipping, and decided against it for now. Not because it's hard, but because I wanted the very first version of this tool to be provably, trivially correct before I add anything that could introduce scanning reliability issues. Low-contrast color choices can make a QR code harder for a phone camera to read, and I didn't want to ship a "customize the colors" feature in the same release as the core encoding logic, since that would make it harder to tell which part of the tool a scanning failure actually came from if something went wrong. Correctness first, customization once I trust the foundation.

I can already tell this is going to be one of the more actively developed tools on the site, just because "encode a URL" is such an obviously incomplete answer to "what should a QR generator do." WiFi credentials, contact cards, plain text, phone numbers — they're all the same underlying QR standard with different data formats stuffed into the same payload. None of that exists yet. This post exists so that whenever it does, there's an honest before-and-after instead of just a growing feature list with no memory of how small the starting point actually was. For today, though, it does one job, it does it correctly, and that's enough to ship. Every future, more capable version of this tool will be judged against how well it holds onto that first part, even as the second and third encoding types inevitably show up.