digital publishing reference
One of InDesign’s minor features is its ability to create and place QR codes, the square barcodes that can encode a variety of information types for fast access and response on websites, menus, product packaging and more.
(The initials, by the way, originally stood for “quick response.”)
From years of seeing and answering questions about it in user forums and other online discussion, I have concluded that many users misunderstand both the feature and the more general subject of what QR codes — what I've jokingly called ”Martian fingerprints” since they first became common — are and how they are created. This primer has three aims:
The last aim should allow designers and even data systems professionals to use ID’s convenient, reliable, standalone and secure QR code generator to fill all such QR code needs—and thus be able to bypass the legions of online and app-based creators which are none of those things.
Published February 2023
1 — QR Code Basics
2 — Creating QR Codes Using InDesign Options
3 — Advanced QR Code Encoding Using InDesign
4 — Exporting QR Codes from InDesign
There may be a tendency for readers to ‘skip to the good stuff’—the specific techniques for QR code creation that follow. I urge all readers to start with this informational and background section, even if it seems unnecessary or too much concerned with irrelevant nuts and bolts. Understanding what QR codes are—and more importantly, correcting any misunderstandings about them—will go a long ways towards effective implemention of the creation and customization information that follows.
A QR code’s rectangular pattern of square dots is a compact way to encode information for optical machine reading, whether the ‘machine’ is a smartphone or a warehouse scanning system. Their use at a consumer/general user level has come and gone over the years since they were introduced. At one time, it was almost mandatory to have them on business cards and such; their use there is now much more selective. But used in the right way, for the right purpose, and with the right data encoded, they are almost irreplaceable as a way to pass along links, contact information and complex ID data in a simple, static, printed source.
QR codes are self-contained. Their entire rationale and purpose is that they require no support system or background database for interpretation; that as much specific information as is needed can be encoded right into the ‘barcode’ itself. UPC codes on products and ISBN codes on books (both more literally ‘bar codes’ because they are read linearly) contain no information except a series of numbers, which are often reproduced along the edge of the bar coding for human convenience. Without a database or other reference, the numbers are largely arbitrary and meaningless.
“Bar” codes are called 1D (one dimensional) or linear codes, because they are read from one line across their bars. QR codes are called 2D (two dimensional) codes, because the entire X-Y pattern has to be read for decoding.
Not so with QR codes, which can hold almost 3,000 characters of data right in the pixelation of the pattern. No database, no online link and no secondary reference is needed for a reader to extract the information. The only thing that's required is for the code be readable: that its printed resolution be adequate to sharply distinguish the black and white pixels, and that most of it be present.
Most, because QR codes use a technique called error correction to both speed their reading and help ensure the information is retained even if the code is damaged, smudged or partially missing. Besides being useful out in the real world, this feature is what allows some QR codes to be partially overlaid with an icon or logo. Such codes are actually “damaged” by the added art, but the error correction allows them to work anyway.
Try creating a fairly complex QR code and printing it out or displaying it at about two inches across. On paper, use something like a coin to obscure different parts of it; on the screen, maybe a snip of post-it note. You’ll find that the code is often readable with a sizeable bite of it missing.
There are four levels of error correction that range from “L” — Low, 7% correction, which can only correct slight errors, to “H” — High, 30% correction—which can make badly damaged codes readable. The higher the level, the less overall data the code can hold, due to the need for redundant data and correction info. InDesign creates all QR codes at the second level, “M” for Medium (15% correction). The third level up is "Q" for Quality (25% correction).
Of course, the information contained in a QR code can be and often are used as a lookup pointer, such as a simple stock number, an encrypted tracking number, or a URL. The ability to encode any number of alphanumeric digits allows more sophisticated pointers, though.
At a (very) technical level, QR codes can encode their information in four different ways, each optimized for a certain type of data and use. In practice, most QR codes that graphic and layout designers will create will use—or will effectively use—straight encoding of bytes in an alphanumeric string up to about 2,900 characters long. The other modes are more suited to encrypted or dense numerical data.
It is important to understand that the data encoded in a QR code, be it a five-digit number or 500 words of text description, is fixed and permanent. Once generated, the information will not and cannot change until a new code is generated using new information.
Put another way, there is no such thing as a “dynamic QR code,” and anything purporting to be such, or any service offering to provide one, should be treated with great caution. It is possible to set up a dynamic response to a QR code, but not a changing, ‘dynamic’ code itself, and the difference is crucial to understand. We'll come back to this point.
To be complete, the one place a QR code might fairly be called “dynamic” is on a web page or kiosk screen, where a code might be rapidly updated depending on user input, choices, time of day, and other factors. Each code itself, though, remains a static element.
But in general, the term “dynamic” as it is tossed around by the various code services and marketing gurus is meaningless — and often misleading! — marketing-speak.
There are only two ways to get data into a QR code: to use an app to generate the latter, given the former, or to use an online service (app or web page) that will do the job for you. It is not possible—within anything like reason—to craft a QR code using graphic skills alone, as can be done (with some difficulty) for simpler bar codes.
If you’re interested in the real 'guts and gears' of QR codes, you will want to at least skim through a copy of the defining standard, ISO/IEC 18004:2015. The complexity is… breathtaking.
The problem then becomes selecting an app or service to produce your QR code or codes. This is not a trivial issue, because the field is laden with pitfalls and outright traps.
First, there are very few completely standalone apps that generate QR codes. InDesign’s is one of the few. The majority, even those that present themselves as standalone or local on computers or mobile devices, use web or remote services to achieve the conversion. And all of the services are, of course, web-based.
This is a problem because some very large number of these services, and ‘app-services,’ are deceptive, convoluted or outright dangerous to use. Here’s why:
So: I unreservedly recommend against using any online service for QR codes, or any app that is not from a highly reliable provider that guarantees the data remains local, secure and unmodified.
InDesign’s QR code feature is the only such app or tool I know of that meets this standard—at least, the only one that is commonly available to designers from a trustworthy supplier. There are undoubtedly much more costly specialized tools out there. But with a little understanding, InDesign’s QR code creator will do any job any designer or information management specialist could need. There’s no need to deal with strangers.
Everything has its price, and for QR codes, more encoded data comes at the price of finer granularity and smaller data pixels in the actual code. Yes, it is possible to encode very long URLs, exhaustive vCard data sets or even short-short stories in a QR code, but the resulting code will grow in number of pixels high and wide, and thus the relative size of each pixel will shrink. The finer the grid and the smaller the pixels, the harder it will be for readers to interpret the QR code quickly (or at all), unless the code is made physically larger for clarity.
At the limit of about 2,900 characters, a QR code will be 177 x 177 pixels, meaning that for each to be a reliable 0.5 millimeter across, the code will have to be about 3.5 inches wide. At a an extreme 0.25mm resolution, the code would have to be almost two inches across, and unless printed with a very clean, sharp process, may not be readily readable—or readable at all—by most QR code readers.
Data size, grid size and readability are opposed forces for QR codes. It is best to keep the data content as low as possible unless you have complete control of the code’s reproduction at a very high quality level.
QR codes can be created in any two colors. InDesign, like many generators, offers a two-color palette to allow creation in almost any code and background color combination. Once created, the graphic image (JPEG, PNG, etc.) can be recolored in any image editor. (This is, for some reason, one of the big come-ons of the pay code services. You have InDesign, which means you almost certainly have Photoshop—or Illustrator, for vector code exports—and can color away to your heart’s content. Be sure to use “fill” and scaling procedures with anti-aliasing turned off, so as not to distort the code pixels.)
Contrast is essential for rapid, reliable reads, so QR codes should be composed of one dark and one light color, if not always black and white for maximum contrast. The smaller the QR code will be presented and the finer the pixel grid, the more essential high contrast between the colors becomes.
In theory, either the code or the background can be the dark color. In practice, a light code on a dark background sometimes seems more difficult to read reliably, especially at higher grid densities. It is well to test both ‘polarities’ as actual prints at the desired size.
While reversed codes are not uncommon (a white code on a black or very dark package background) and the contrast rule is sometimes ignored (such as with one color of printing on the silvery aluminum of a drink can), using a dark code on a light, matte background is recommended.
All QR codes, generated for any purpose or by any method, should be tested before they are placed in general use. This is doubly important for any printed use, and triply so for any printed use where a large volume or high cost of printed goods is involved.
A quick test with any convenient reader (smartphone, tablet, etc.) is good enough for development of a a project. But at completion, before a digital production is released or a printed project is sent to press, each QR code should be tested with as many readers as might be at hand — ideally, at least one Android and one iOS device, and if available, an older version of each. For print, the testing should be done on the very final PDF generated, either from the screen or (better) from a test print.
Testing should ensure that the code reads quickly (a variable, based on the reader and the complexity of the code) and accurately... and then, if the code requires some action (SMS or email send, web link, WiFi login) its functionality should be tested through completion.
The InDesign QR code creator, accessed under Object | Generate QR Code, is a full-featured QR code generator that has five different data input options, all of which deal with the data as alphanumeric characters. (Technically, as bytes; there is another QR code mode that uses alpha characters more directly.)
The differences between the options are largely in how the data is entered into an input form. The generator then applies (alphanumeric) content formatting for the code so that it is correctly interpreted by readers.
As set up for use within InDesign, it will produce:
InDesign has the significant fault of creating only v2.1 vCard codes, an older standard which has several limitations, the worst of which is that accented characters will be mis-encoded and read as garbage on most modern QR code readers. This limitation can also be bypassed by using the custom process.
The actual encoding and structure of the first four code types will be discussed in the custom section below.
It is this plain text entry mode, however, that allows us to use InDesign’s QR code generator for completely custom codes.
By entering pre-formatted text in the Plain Text entry mode, QR codes of any of the predefined types may be created, along with improved and extended versions of them, as well as codes of other types not directly supported by ID’s entry options. Each of these modes is discussed below, along with a comparison to the default ID feature, if applicable.
ID’s QR codes, like the vast majority of QR codes in use, are simply a text string of a few to hundred to thousands of alphanumeric characters. It can be difficult, though, to read the raw encoded string from a graphic code; readers read, decode and parse the information into formatted display, stripping things like SMS, URL and vCard field codes. It can thus be difficult to analyze a code’s real contents, learn how a new code type is formatted internally. or diagnose problems with a code.
There does not seem to be a good “raw” QR code reader that will simply display the encoded string, although some claim to do so in their app store listings. (Many... fib about such things.)
Within InDesign, at least, though, there is a subtle workaround. When you create and place a QR code, you can hover the cursor over it… and the popup data will be the actual encoded string, or at least the first 100 or so characters of it. This will not work for QR code images from other sources, placed in ID, or codes encountered anywhere else. That “good raw reader” is sorely needed!
There may be times when all that is needed in a QR code is plain, unformatted text content. This could be used to encode warehouse storage info, book summaries, clues for open-field games or art displays, or the like.
Usage is simple: enter the text you want the code to return, using only characters from the ISO 8859-1 standard.
You may have to expand this image in its own tab to enable readability.
InDesign has a default entry option for SMS (text) QR codes. There is little reason to use a custom entry method for this, but for reference and to enable custom, mass or script-driven entry, the encoded string format is:
SMSTO:<phone num>:<message up to 165 char>
A common QR code use is to encode a phone number, much like SMS without the attached message. InDesign has no default entry option for TEL, but it’s trivial to implement using custom entry:
InDesign has a default entry mode for email codes. Again, there is little reason to use custom entry, other than for repeated or scripted creation, but the code format is as follows:
SUB:Automating email barcodes;
Hope you got the lunch invite.
This is just a reminder that email can be encoded into QRcodes should you ever want to do such a silly thing.;;
You can also use the web/HTML ‘mailto:’ protocol in a QR code. References for this protocol, which allows more complex header information, can easily be found by searching.
InDesign of course has a default entry option for web addresses, which is perhaps one of the two most common uses for QR codes. The default entry mode works well enough, but using a custom entry gives the designer more control over the code content, as well as the aforementioned ability to automate or script their creation.
Once again, most readers will present the URL for review before continuing to a web destination, but some readers may be configured to open the site immediately. The latter is a very bad idea, especially in the era of endless malware etc. No one should ever have their device automatically open any QR code web destination or link, and should always review scanned links before giving approval to proceed!
This is where a “dynamic” QR code can be created, under the full control of the creator.
If the URL points to a redirection address, the code and URL will always remain the same, but the destination reached by users can be changed as often as desired. These could be:
If you are putting a contact or new-customer QR code on products or materials that may have a shelf life of years, using this redirect method will allow you to update your welcome without former customers or subscribers losing the link.
A spectacularly useful QR codes purpose is to present WiFi network login information. This is best for public-use networks such as those in libraries, coffee shops and the like since the password must be openly encoded in the QR code. However, for guest networks, it makes login a snap for any visitor.
(This also enables frequent changes to the network information, so that shops can readily shed nearby “vampire” users who obtain the login and then continue to use it from their apartment or office. Actual visitors can snag the new login info in a moment, even if if changes every day.)
(No useful QR code example for this one.)
Although use is selective, geographic coordinates of extreme precision can be encoded into a QR code. This could be used to establish geo-caching, trail or even aviation markers, or markers to set a map location to an intended destination.
This is the big one, in at least two ways. Along with URL codes, contact-info codes are probably the biggest use of QR codes. They were once somewhat faddishly required on business cards; although less often seen there these days, they are still useful to transfer contact information quickly and accurately.
As noted, ID’s default “business card” data entry will only encode the information using the vCard format, and in the older — obsolete, really — v2.1 standard at that. As more than one frustrated designer has found, v2.1 doesn’t handle accented characters. There are also other contact-info formats some designers may wish to use (or, more accurately, their employer or client may wish to use). So, if there is any QR code format worth learning to do in this custom mode, Contact Info is it.
While vCard seems to be the dominant and most widely used contact information format (especially when contained in .vcf files that can be attached to various message types), there are other contact-info formats in use. The most common of these is MeCard, which was developed in Japan for exchange of a limited contact information set between smartphones. Fortunately, the formats are similar enough that most devices seem to be able to read both, although information from whichever is the less compatible format may not be parsed into correct Contacts or application fields.
You can also create QR codes encoded with MeCard data; the chief limitation of the format is fewer overall field types and no support for multiple fields of any one type. A fairly complete listing of the format and field types can be found here:
We'll stay with vCard in the remainder of this discussion. For those who like a detailed reference, here are two. One is another Wikipedia entry that presents a reasonably good overview, and the second is the current full — and rather dense — vCard standard declaration. Both are useful in their place:
This is, oddly enough, one of the most coherent and comprehensive pages on the basics of vCard formatting out there. It may be all you need to write more complex QR code versions, although its organization is a little loose and you will have to, for example, carefully look for required fields and their coding.
The comprehensive standards document for vCard, including some proposed extensions. Dense, but if you want to know all the standard codes you might use, their formats, and their requirements, this is the doc to bookmark.
There are three versions of vCard in use. Version 2.1 is still common, but has many limitations and should be avoided. Version 4.0 does not seem to be widely implemented, even after some ten years; it may be a case of simply adding too much complexity to what should be a simple data format. Version 3.0 seems to be the happy midpoint: supported by nearly all current devices and readers, but with no limitations in most modern uses, either. Unless otherwise noted, we will be discussing and working with vCard v3.0 for the remainder of this discussion.
InDesign’s entry form allows input of one of each basic field type (following, oddly enough, the MeCard protocol). Besides the fixed v2.1 encoding (which, again, does not permit accented characters in the data fields), this limited structure may not accommodate your needs or those of your company or client. Fortunately, vCard (3.0) is a flexible format with dozens of defined field types, and nearly all can be duplicated to allow multiple email addresses, phone numbers, etc.
Let's start with a fully populated InDesign vCard, for reference, comparing the input fields with the resulting encoded string:
Fairly obvious and intuitive, but observe the many small details of the field names, separator characters, etc. (And yes, both the N and FN fields are needed.) But there are many things missing here, as well. For one thing, there can be three more fields in the N field (middle name, prefix and suffix). The telephone numbers and online address can be other than WORK, etc.
In perhaps the most important variation, if you were to enter that same block into Plain Text, but substitute VERSION:3.0 for the second line… the resulting code would be interpreted under v3.0 rules, which would allow any field to contain ‘upper’ characters such as accented letters. Yup, it’s that simple.
The InDesign export is following v2.1 convention for field parameters in using, for example, WORK in place of the v3.0 TYPE="work". Either seems to work in most cases, but it is probably sensible to use the newer definitions over the outmoded ones.
Here is the most basic vCard format, with the minimium required elements in the required order:
The N (structured name) and FN (formatted name) fields are required even if empty.
With this basic frame, the information from the full InDesign version above, and the two resources listed, you should be able to create vCard codes of almost any combination of content.
And here is a more extended vCard format, which you may cut and paste and edit as necessary.
TEL;TYPE="work":<work phone number>
TEL;TYPE="home":<home phone number>
TEL;TYPE="cell,text":<mobile phone number>
Basic notes for formatting fields and parameters in this structure are as follows:
When the above basic structures, keywords and information begins to make sense, most designers will want to refer to the complete vCard definition, RFC 6350, which specifies several dozen parameters including added personal information (gender, birthday, anniversary), company information, organizational information such as time and datestamps, and more. The link is above.
If you use QR codes only within InDesign projects, the integral nature of the code generator offers its full power. Codes are live elements that can be resized, managed with many of ID's layout tools and features, previewed by hovering over them and edited with a simple right-click.
If, on the other hand, you want to use InDesign as a code generator for exported/outside use, it has other advantages. It is, of course, completely stand-alone, doesn't embed unwanted mal-code around your content, isn't tied to a pay service (well, other than the Adobe subscription), is as secure as your workstation happens to be, and is more or less free.
A further advantage of InDesign, especially using the custom code techniques above, is that code creation can be managed with scripting and other automation, making things like generating a large series of vCard, warehouse, event badge and other codes relatively simple.
But you have to get the darn things out of InDesign to use them in, say, web pages or projects created using other applications. Here's a streamlined method for that.
In a nutshell, an InDesign document intended for QR code creation and export should have small, square pages. That will eliminate any need to crop the exported graphics.
To expand that notion:
With the "isolation zone" around the pixel area, this will generate a QR code of about 950 pixels square, high enough resolution for almost any purpose, but still as a conveniently small file (typically 5-100k).
If you are creating only relatively simple, “coarse” codes, you could go down to 3 inches, or even 2. But two-color, gray-space PNG files are very small anyway... may as well have the resolution to use! 4 inches should be enough for the finest granularity most high-content codes will create, but if you are creating text codes with large content and thus a very fine screen, using a 5 or even 6 inch page might be wise.
From there, you can color the exported codes in Photoshop if you want to be fancy and faddish. Be sure to use dark colors to maintain adequate contrast, and be sure to turn off all anti-aliasing and use resizing that preserves hard edges. (Letting the pixels get fuzzy will reduce read reliability)
Embedding logos is a try-and-try-again thing, and will probably not work very often since ID exports QR codes at the second-lowest of four error correction levels. (If the maximum level, H, was allowed, it would probably be a snap to cover up the middle square with a logo.)
Within ID, it's just a matter of hovering over a code or even opening the code editor to identify it. Out in the exported realm, if you have multiple codes for a project or library, careful file naming can help keep things sorted out. In some circumstances, putting a small text code in the isolation margin of each code will give an immediate identification, won't interfere with code reading and probably won't be noticed by most human readers or users of the document. (You can always “tuck in” the graphic margin to hide the identifier as a late/last step, too.)
So there you have it, InDesign users — a method to create almost any useful QR code format, with automation and scripting potential and full control, with no security issues, malware potential, ‘pay-me’ or usage limits, and all at no extra cost. Go fill the world with more “Martian Fingerprints.”
Here's a link code for this page, all fancied up and everything: