A few days later, the code stopped taking people to my website. The service wanted payment to keep it working.

As a software engineer, I wanted to understand what had actually failed. The QR image had not changed. The dependency behind it had.

The hidden dependency: a redirect

The code did not contain my website’s URL. It contained a URL controlled by the QR provider, which redirected visitors to my website.

That adds another service between a scan and the destination:

your phone → provider’s redirect URL → destination website

A direct, static QR code has a simpler path:

your phone → destination website

That distinction matters when a code is already printed on packaging, a poster, a business card, or a restaurant menu. You can replace an image on a website quickly; replacing printed materials is a different problem.

Static and dynamic QR codes solve different problems

A static QR code stores its payload directly. For a website, that payload can simply be the destination URL. The QR image itself does not need a subscription or a redirect service to keep encoding that address.

That does not mean the destination is permanent. The domain still needs to be maintained, the page needs to remain available, and the printed code needs to be readable.

Redirect-based, often called dynamic, QR services can be useful when you need to change a destination after printing or collect scan analytics. Those features require infrastructure, and charging for them is understandable.

My problem was discovering that dependency after I had already started using the code. For my use case, I only needed a direct link.

First an Android app, then a browser tool

I built an Android QR Code Generator so people could generate and customize QR codes without that unexpected redirect subscription.

Then I asked myself: why should someone install an app just to generate one QR code?

That led to the web version on QuickConvertOnline:

• QR Code Generator for creating individual codes.
• Bulk QR Code Generator for creating multiple codes.

The web QR tools generate codes in the browser. The principle is straightforward: when you enter a destination URL, the generated code should encode that URL directly rather than quietly substituting a provider-controlled redirect.

What I check before printing a QR code

Whether you use my tools or another generator, I recommend a short check:

1. Scan the downloaded image and inspect the decoded URL. Is it the address you entered?
2. Open it on another device and confirm that the correct page loads.
3. Test the actual printed size, contrast, and surrounding white space.
4. If you deliberately choose a redirect service, check its pricing and what happens when a trial or subscription ends.

A successful download is only the start. The important test is whether someone else can scan the final code and reach the intended destination.

A small frustration became a broader project

I later added tools for PDFs, images, video, audio, and other everyday tasks. QuickConvertOnline grew from that original QR-code problem, and I am still improving it.

The lesson I took from this was practical: even a tiny utility has an architecture, and that architecture decides which dependencies users inherit.

For a simple QR code linking to a website, I wanted that dependency to be the website itself.

Have you encountered an unexpected redirect or subscription dependency in a tool you thought was self-contained?

Adapted from my original Medium article, with additional technical context for Hashnode.