About Custom Data QR Codes
Most of the QR code types on this site work by following a rulebook. A WiFi code has to look like WIFI:T:WPA;S:...;P:...;; or a phone won't recognize it as network credentials. A vCard has to open with BEGIN:VCARD and close with END:VCARD or it won't offer to save as a contact. A custom data code follows no rulebook at all. Whatever you type goes in as raw text, exactly as entered, with nothing interpreted, validated, or reformatted along the way - which makes it less a QR "type" in the usual sense and more a blank canvas for anyone whose own systems already know how to make sense of a particular string.
That's a narrower audience than most people generating a QR code for the first time, and it's worth being clear about who this is actually built for. It's the right fit when a piece of software you already run - a warehouse scanner, an inventory system, an internal asset tracker, a point-of-sale terminal - expects data in a specific shape that has nothing to do with how a phone's camera app behaves, because nothing here is meant to be read by a general consumer's phone at all. A logistics operation might encode a shipment ID and destination code as a compact JSON object - something like {"id":"SHP-88213","dest":"WH-04"} - that a handheld scanner on the loading dock reads directly, skipping a network lookup entirely for a routine internal transfer. A library or small archive might stamp a delimited string onto the back of a physical item, encoding a catalog number and shelf location that only its own lookup software understands. None of this is meant to be pretty on a phone screen; it's meant to be fast and unambiguous for a machine that already knows what to expect.
This is also where it's worth understanding the QR standard's actual data modes, since a custom string may unintentionally cross into a less efficient one. Digits alone can use the compact numeric mode. Upper-case letters, digits, and a small set of symbols like $, %, and space can use alphanumeric mode, which is noticeably more space-efficient than the alternative. Anything with lower-case letters, punctuation like colons or commas, or non-ASCII characters drops into byte mode, which uses more of the code's finite capacity per character. If your internal format allows some flexibility - say, choosing upper-case identifiers over lower-case ones - you can sometimes pack meaningfully more data into the same size and complexity of pattern just by staying inside the more efficient character set.
Where this type is clearly the wrong choice is anywhere a general audience will be scanning with an ordinary phone camera expecting normal behavior - a link opening, a contact saving, a network joining. Feed a JSON payload or a pipe-delimited string to someone's default camera app and the best case is that it displays as an unhelpful block of text; there's no browser opening, no action taken, nothing but raw characters on screen. If you find yourself wanting a phone to actually do something with what's scanned, one of the structured types elsewhere on this site - URL, vCard, WiFi, an event entry - is almost certainly the better fit, since those follow a format phones are actually built to recognize.
Because nothing about the structure is checked on the way in, correctness is entirely your responsibility and your downstream system's. It's worth testing a generated code against the actual scanner, app, or parser that will eventually read it, ideally before committing to a large print run or embedding it into packaging that's expensive to redo. A misplaced delimiter, an unescaped quotation mark inside a JSON string, or an extra space where your parser doesn't expect one can silently break the receiving system even though the QR code itself scans perfectly cleanly - the pattern doesn't know or care whether the text inside it is valid for its intended purpose.
Where this type is a poor fit: anything meant for a general public audience with an ordinary phone, or any case where you're tempted to reinvent a wheel that already has a standard - encoding a web address, a contact, or a WiFi password as raw custom text throws away the native app behavior those dedicated formats trigger automatically. Reach for a structured type elsewhere on this site whenever one genuinely matches what you're trying to do, and reserve this generator for the cases those formats truly don't cover.
It's also worth building in a little foresight if these codes are going to exist at any real scale. Give your internal format a version marker or a consistent prefix if there's any chance the structure will evolve later, so a future scanner or parser update can tell an old-format code apart from a new one instead of failing silently on codes printed before the format changed. And if the encoded string carries anything sensitive - an internal reference number tied to a customer record, for instance - remember that a QR code is just as easy for an unintended person to scan as an intended one; keep genuinely sensitive lookups behind an authenticated system rather than embedding the sensitive data itself directly in the code.