A QR Code has a version range from 1 to 40. This information tells about how much data is stored within it. Version 40 has 177 rows and 177 columns (in some decimation called ‘modules’) for 31,329 pixels. It should be immediately clear at this point that this is the hypothetical maximum that doesn’t take into account the error correcting or any of the other infrastructure of the QR code itself.

Once error correcting, infrastructure (the fixed patterns, for amount of error correction, targeting, frequency, mask patterns and such) and minimal error correcting get added, this is maxes out at 23,648 bits (2956 bytes – high level error correcting on version for is 10,208 bits 1276 bytes).

A version 40 barcode with 1276 bytes of data:

Once you get into the high capacity barcode area, you get into color 2d barcodes. The back and white barcode technology tends to max out fairly quickly (data matrix can only hold 2,335 alphanumeric characters (not bytes)).

To go beyond the size limitations of version 40 in a QR code, one can used the Structured Append (encoding mode 0011), though a quick search of various QR code reading libraries suggests that it is not something that any of them support.

A not uncommon approach for an alternative is instead to store a tag of data in the barcode which then references an online resource that has the full information. Note that this works poorly in offline situations.

For dealing with much smaller chunks of data (300 bytes), 2400 bits of data can fit into a low error correcting version 11 QR code (it has 2592 bits of data to use for 321 bytes)

At this point, with lots more data space between version 11 and version 40, there are a number of encoding options if there are difficulties of getting the byte[] out of the data. One could encode it in the alphanumeric character set that QR code allows (44 characters designed for web addresses – 11 bits for 2 characters in versions 10-26), or numeric (12 bits for 3 digits in versions 10-26) as the two easiest ones to work with.

Putting too many bytes into a QR-code is not a good idea. The generated QR-code will be big and difficult to manage and read.

A better strategy is to link the data into an URL and turn the URL into a QR-code; there is no limit on the URL linked resource. You can put images, SVG, html, text file…

If your QR-code needs to represent structured information (e.g metadata), you can put an XML document at that URL.

There are some services that do this for you, for instance: metaqrcode.com

This strategy has some pros and cons:
pro :

• you can change data without reprint qrcode
• no big QR-codes
• smaller QR-code are easier to read

cons :

• you need an internet connection to read data

A QR Code has a version range from 1 to 40. This information tells about how much data is stored within it. Version 40 has 177 rows and 177 columns (in some decimation called ‘modules’) for 31,329 pixels. It should be immediately clear at this point that this is the hypothetical maximum that doesn’t take into account the error correcting or any of the other infrastructure of the QR code itself.

Once error correcting, infrastructure (the fixed patterns, for amount of error correction, targeting, frequency, mask patterns and such) and minimal error correcting get added, this is maxes out at 23,648 bits (2956 bytes – high level error correcting on version for is 10,208 bits 1276 bytes).

A version 40 barcode with 1276 bytes of data:

Once you get into the high capacity barcode area, you get into color 2d barcodes. The back and white barcode technology tends to max out fairly quickly (data matrix can only hold 2,335 alphanumeric characters (not bytes)).

To go beyond the size limitations of version 40 in a QR code, one can used the Structured Append (encoding mode 0011), though a quick search of various QR code reading libraries suggests that it is not something that any of them support.

A not uncommon approach for an alternative is instead to store a tag of data in the barcode which then references an online resource that has the full information. Note that this works poorly in offline situations.

For dealing with much smaller chunks of data (300 bytes), 2400 bits of data can fit into a low error correcting version 11 QR code (it has 2592 bits of data to use for 321 bytes)

At this point, with lots more data space between version 11 and version 40, there are a number of encoding options if there are difficulties of getting the byte[] out of the data. One could encode it in the alphanumeric character set that QR code allows (44 characters designed for web addresses – 11 bits for 2 characters in versions 10-26), or numeric (12 bits for 3 digits in versions 10-26) as the two easiest ones to work with.

Putting too many bytes into a QR-code is not a good idea. The generated QR-code will be big and difficult to manage and read.

A better strategy is to link the data into an URL and turn the URL into a QR-code; there is no limit on the URL linked resource. You can put images, SVG, html, text file…

If your QR-code needs to represent structured information (e.g metadata), you can put an XML document at that URL.

There are some services that do this for you, for instance: metaqrcode.com

This strategy has some pros and cons:
pro :

• you can change data without reprint qrcode
• no big QR-codes
• smaller QR-code are easier to read

cons :

• you need an internet connection to read data