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 byte-wise. 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 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, probably arranged like ⡿ in the very top of the data portion (Row 10 and below). 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.