Nah, it’s 30%, and very much depends on how the damage is laid out.

• The corner squares (finder patterns) must keep a ⬜⬛⬜⬛⬛⬛⬜⬛⬜ cross-section at most angles. Most readers will accept even round ones. This applies to the smaller squares (alignment patterns) on larger QR codes too.
• The zebra strips ⬛⬜⬛⬜⬛ (“timing patterns” if you’re a nerd) connecting the finder patterns must remain intact. Very few readers can correct for errors in that.
• At this point, a good reader will be able to detect the QR code’s position in the image and its resolution (“version” if you consume ISO propaganda), and thus calculate the location of every pixel (“element”, ditto). Each of those will usually be sampled at a radius of around ⅓ of the distance between them. This allows for slightly wavy codes but also codes with rounded pixels or even unrelated content in the edges. (For the record, this is lazy and I prefer this version of the concept that uses almost up-to-spec QR codes.) Google Lens is more sophisticated than just using a 3D perspective transform, as I already mentioned.
• One line of pixels around finder patterns is necessary for decoding (mask and ECC level info) and has basically no error correction so it should be also clear except the ⅓²=⅑ trick described above.
• The data is stored with robust Reed-Solomon correction, which is bytewise. You can safely cover about half of the advertised recoverable area with contiguous damage anywhere except the sections mentioned above. Still, you can damage more area (and reach the advertised percentage) by taking several things into account:
  • Know how the data is laid out in the specific QR resolution, and keep in mind that Reed-Solomon is bytewise. Thus, you want to damage as few bytes as possible, and for most total area, the strategy is to ruin all 8 bits in each. Without deeper analysis (looking up the byte layout), a good rule of thumb is that vertical damage aligned to an even number of columns from the right (skipping Column 7 with the vertical zebra stripe and thus no data) is likely to ruin the least amount of bytes partially.
    • Looking up the byte layout will also reveal that there are probably 1-7 unused pixels in the leftmost two columns (marked “X” in the image), probably arranged like ⡿ in the very top of the data portion (Row 10 and below) or ​⣷ in the very bottom (Row 9 from last anď above). These can be damaged without consequence!
  • Damage whose very dark spots line up with original black pixels (and vice versa) does not really count. Keep in mind that while using this strict definition of damage results in way fewer damaged bits, those are most likely not contiguous, so only a few 8-bit bytes will remain intact through this.

With hand drawn codes it’s also that the scanners are very good. It’s no good having high redundancy if the scanner can’t transform the 3D code to a square and find the timing bits etc

Print one out at 1:1 scale and wrap it around your wrist, then test it. Curved surfaces are challenging for QR code readers. AFAIK Google Lens is one of the best ones (it will follow edges of pixels in wavy codes) but you’ll want any old open source one to work.

Hey OP, I’ve seen a lot of tattoo artists recommend not getting QR codes tattooed because they fade and smear over time. Also, I don’t wanna sound overly dramatic, but with the current political landscape being to aggressively cut government programs, I wouldn’t trust a domain name being around forever. It may still be better for the code to be one you control (they’re like $12 a year) and set it to redirect there instead.

Tattoos can get a little blurry over time, especially when they are really small. Look at examples of people who get little quotes or words written in cursive, sometimes they become almost unreadable.

I don’t know either if lack of a slash after domain makes for an invalid URL, I think they will just work, similarly you can just type “time.gov” into the address bar and the browser knows to try HTTPS on port 443 and HTTP on port 80, and request the document path “/” (explicitly, this is “https://time.gov/”). Lemmy and Fennec automatically add trailing slashes to them, apparently. However, you can cheat that by creating a hyperlink whose display text is “https://time/.<zwsp>gov” where “<zwsp>” is a zero-width space.

By the way, “www.” is a subdomain like any other, but people tend to add/remove it at will so it is considered good practice to make a redirect, or point the DNS A (IPv4) and AAAA (IPv6) records to the same server, and mark one copy as “canonical” (this is required by search engines). Yet, there are many servers that only work with or without “www.”, and possibly some where the content differs.

Edit: that “explicit” URL got the port (:443) edited out by Lemmy!