Data entry sucks.

You could also use this as a basis for a printer+scanner system that exports and imports your system key store(s) automatically without having to risk OCR breaking your import.

Scanning a QR code is also just useful when it comes to entering long random strings. Although I agree that such a tool would do better outputting in plain text as well in case you need to enter it without a phone on hand, I think adding a QR code for loading the files quicker still makes sense.

So if you have more than a handfull of bytes you may have to actually read it "by hand" to fix errors.

These days I keep the really important keys both as a qr codes and also hex. But the hex is not pleasant to work with.

Easier reading back. You don't want to be typing your private key in, and while scanning + OCR might be pretty reliable unless you are daft about font and text size choices getting text direct from the QR code on your phone (or direct into a PC/laptop if you have a scanner that perhaps types the content by pretending to be a USB keyboard), feels to me like it would be more convenient.

You can store a 2048-bit RSA private key in standard text form in a QR code, so after scanning to clipboard all you have to do is paste the text into an appropriate file, or again using the scan->HID option that is slightly more direct.

For longer keys you will need multiple QR codes, of course, and a very slightly more convoluted method. I have a couple of keys, SSH private keys and the master key for a keepass store (which is also on a USB token I carry), printed as QR codes stored in a secure place in this manner.

It looks like this tool does not allow for direct input from scanning the QR code(s) in the manner I've just described, as the description says it includes metadata for reassembly of larger data removing the simplest case for small data in favour of making larger data more convenient/robust.

It is a really fun idea and does not require deep technical knowledge to operate. The intent is for Bitcoin secret keys, but it can be used for any secrets.

https://secretcodex32.com/

https://superbacked.com/

It uses Shamir's secret sharing algorithm to generate shares where the private key is split in n shares with k needed to reconstruct it. The bytes are encoded as word on a PDF (either 'burnt in' or written manually with pen to minimise the risk of storing them on printers etc).

That way you can spread the risk of loosing the physical key, while still maintaining some assurance that e.g your friends can run away with the key (or be compelled to hand it over to some threat actor).

[0]: https://github.com/filleokus/hemlis

While you pose a valid concern, I think most people don't have to worry about this. The reason is that printing private keys isn't a common practice, so I think it's unlikely that nation-states mandate backdoors in printer firmware to collect private keys, and most people don't have to worry about targeted attacks.

EDIT: On a second thought, your comment reminded me of that creepy time many years ago when a printer randomly regurgitated a partial print of a document I printed some time before (read: days or even weeks before), clearly showing that the printer kept it somewhere in memory. So it still possible that some printers memorize what you print. IIRC it was a Brother printer. At the end of the day, you can't account for every possible attack vector. Pick a reasonable threat model and act accordingly.

[0]: https://github.com/matiaskorhonen/paper-age

Edit: I now see it was already mentioned.