It generates the smallest QR Code possible (Version 1; size 21×21).

Other URL shorteners generates bigger QR code (usually version 2 or 3)

Bit.ly code: https://bit.ly/3l9tI3w (8 + 7 + 7 = 22 chars)

Ku.ag code: https://ku.ag/t002te0h.y-e (8 + 6 + 12 = 26 chars)

Every string encodes to the same amount of “squares” in a QR code, so I see no reason to use your service.

> Every string encodes to the same amount of “squares” (...)

Actually the size of QR Code doesn't depend only on length of the string but also on charset used.

For instance, the URLs generated at bit.ly are case sensitive, to encode the qr code you have to use "binary" input mode.

For KUAG I'm using "Alphanumeric" input mode, it reduces the size of the QR code I'm generating however I restricted to a smaller subset of character.

I understand it looks like a paradox; but a bit.ly shortened url leads to a bigger QR code than KUAG (even if the string is longer)

See https://en.wikipedia.org/wiki/QR_code#Storage for more details.

Note: the shortened url I display is 'lowered' for esthetical reason.

Edit: I forgot to mention the error-correction. But I don't think it's fair compare with other shorteners if they are not using the same error-correction level.

Oh, fair point, now it makes sense and I see value in your product!

> Every string encodes to the same amount of “squares” in a QR code

That's not correct. QR codes have redundant pixels, and you can choose how much redundancy you want.

That said, the default in most generators is the least amount of redundancy.

Every content byte encodes to the same amount of squares. Error correction bytes are “appended”. The point about every string being equal in the same configuration of a QR code still applies. As such, the shorter URL, the better.

Not every string uses the same amount of content bits per character.

If you use only numbers you use 3 1/2 bit per character, if you use only numbers, uppercase letters and some limited punctuation it’s 5 1/2 bits per character. Otherwise it’s 8 bits per character but that’s a waste because most of the characters you can then represent can’t be used in a URL.

I wonder if Google will introduce something stupid like an emoji that means https:// , that will start showing up on Chrome and be recognised by their QR Code scanner..

Oh never mind, they're going to kill the address bar instead. Next they should just introduce an emoji that means "Search for this on Google:"...

I wonder what the minimum necessary text is for recognising a link in QR code apps, the one built into my camera won't notice that some text that says facebook.com is a link, but the one in google lens app will.

You were downvoted, but that question is the interesting thing about this. It'd be nice to know a little about how it works.

Would you be interested to read a blog post about how it works?

I consider to write a few articles about each part of the project... if there are people to read them! ;-)

I am fairly content with your reply here:

https://news.ycombinator.com/item?id=24691042

But I am one of the people who would read a blog post elaborating further if that's something you chose to write. :)