QR size changes when I alter the Correction level

May 21, 2014 at 9:48 AM
If I select a set size for the QR code, lets say 90px and then I alter the Correction level the actual pixel size of the QR codes alters. It varies depending on the Correction level selected. Therefore I can never get an exact QR code size.

Really would appreciate some help on this as I need to get these codes printed and I have tried everything I know to stop the size changing.

I also was trying to get a 49x49 QR code but the Library doesn't seem to accept it. Again I just get an odd size generated.

May 22, 2014 at 1:23 AM
If you setup as fixed code size then code will be according to that size or smaller.

This was design decision I made before, that quality of code is on priority instead of blend image. If you want explicit correct size, then use fixed code size on DrawingBrushRenderer.


It will scale code to specific size.

49x49 is a bit tricky. In some case encoder will ignore that size, since if we have 49+ module per each side, then we cannot display code properly in 49x49 px image. You won't be able to read it by decoder.

Image without blend and with all cell proper rendered is on first priority than just give you what you want. 49x49 is way too small for medium size QrCode.

I would suggest that 49x49 code should be either scale down version or just a dummy code, while you click on it, it should give out large image. If you render out on website, then css can do all the work without need of small image.

Short string input, with sharp rendering without blend is best practice when you want your client able to decode it with any mobile and at longer distance. Try to do some decode in real environment under different condition you will know why I made such decision. Not just send perfect image direct to decoder.
May 22, 2014 at 1:51 AM
Edited May 22, 2014 at 1:52 AM
Thank you for the swift and comprehensive reply.

I agree that the cell properly rendered is the most important thing. I was also wondering if 49 was probably a bad size to aim for :)

The reason I need something about this size is that I need codes for a wrist band. The print area is only 12mm x 12mm and so I was trying to get the largest and clearest and most accurately read image possible to fit that area.

In your experience, if that was the area limitation, 12mm x 12mm what would you recommend as a settings to go for as to size and correction etc etc, so that when the code was read, it was 99% times read without trouble. The data looks like this ; http://www.mywebiste.com/?user=AU00000001

thanks for your help
May 22, 2014 at 11:14 PM
First shorten that url. There are a lot of different shorten service out there. In most of time, those service provide consistent url length which is also good.


You could write small app for that to generate massive amount of shortened url. Shorten as shorten url include user id as whole not just your site url.

Once url is short, amount of code cell should decrease a lot. Generate one and give it a try, record how many cell per each side.

Level 1 Code. holds 17~25 characters (alpha numeric or acs ii) 7~10 with high error correction
Level 2 Code. holds 32~43 characters (alpha numeric or acs ii) 14~20 with high error correction

Here is a shortened url: http://goo.gl/xwCNC

19 characters. Level 2 code with medium to high correction, or level 3 code will do.


Choose iso-8859-1 character encode, quality H with shortened url. It is about 29x29 cells, quality Q is 25x25 cells.

For quality H. better size will be 29x29 or 58x58.
For quality Q. better size will be 25x25 or 50x50

Above are all with outside border set to zero cells. If add border, it will of course require larger size. But in most case, when you print on something, you won't print code's edge to target's edge anyway. So ignore border sometime is alright.

This should give you some idea how you should do it. Shorten URL is KEY. With your above url it will be too long to make it easy to read.
May 22, 2014 at 11:22 PM
Additionally, reader is important too. QrCode reader 90% of them are junk. Faster and accurate reader is hard to find.


i-nigma is very good reader. Code read speed and error correction is on top of chart. Hard to find it as it's name.
May 28, 2014 at 9:58 AM
Thank you for taking the time to detail all of this.