Is your feature request related to a problem? Please describe. Suppose you and your friends go out and take a lot of photos. If you want to transfer them losslessly, you can only upload them to Google Cloud. You have to upload them to the cloud first and then use QRshare to share the link. This is very troublesome.

Describe the solution you'd like Support sharing pictures and videos

Describe alternatives you've considered If it's a file size issue... then only limit sending photos?

May 30 '25 15:05 internet-coffee

I'm not aware of any methods of converting media (image/videos) to QR codes, but it might be possible if it is converted to base64?

QR codes have a max file size limit of around 3kb. It's slightly smaller with the XZing library at around 2kb.

I imagine that the file size limit with the base64 encoding overhead will make it lower.

This is worth looking into, but might not be possible with high res photos.

May 30 '25 18:05 mrwm

I did a quick test with a few resources, and here are my findings.

Without encoding anything:

Wikipedia 1kb image

https://commons.wikimedia.org/wiki/File:1kb.png
- XZing is not able to handle the 1kb image.

https://github.com/user-attachments/assets/e5c16e16-7365-40ff-b1d4-b89a1499bf6b

A smile image I created at ~601Bytes:

https://github.com/user-attachments/assets/c9d666b4-2e99-4f7b-807f-adfeb01d9bd0
- This worked... but obviously did not transfer on the other phone

So converting images directly to QR code doesn't work... On to the next part: Converting the image to base64, then to QR code!

Nov 15 '25 23:11 mrwm

Converting to Base64 then to QR code:

Using the same smile image above

Knowing that the 1kb file doesn't convert without converting to base64, I'm not going to try it in base64 either.
Conversion to base64 worked... but doesn't have the desired outcome for transferring from one mobile device to another.

https://github.com/user-attachments/assets/6404cf51-ea3e-4a27-a8a2-742e535b08d6

The results:

It does not work... at least it doesn't work as I would expect that mobile browsers would work.

Here's the Base64 encoding of the image:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA8AAAAPCAIAAAC0tAIdAAAAAXNSR0IB2cksfwAAAARnQU1BAACx
jwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAAAAlwSFlz
AAAuIwAALiMBeKU/dgAAAAd0SU1FB+kLDxYJMUqbpRwAAAGvSURBVCjPjVK9yupAFMzG3fznM0SC
hQgKIqKFYmvjC/gAPqWtlYhFsPAJTCcWiZqQXYxmdbN7i3jV71Z3qlPMGeacGSCEkP4b8D19rwEA
xF8AAGRZ/sWmlGKMKaWqqpqmyRgjhHDOdV23bVtV1XIBlqoYY9/39/t9p9MZDodJkmy326IoxuNx
v99HCJVs+a0dBMFisQiCIE3TMAw3m81qtbpcLpzzf32rqtrtdufzeavVsiyrVqtNp1NJkhqNhqZp
b99ACME5z/M8juM8z0ujWZYlSYIQcl23Wq0ihAAAkiRBxtjz+cQYn04nQojrurqu3+/3MAwRQhBC
wzAghC92URSU0iiK1uv1brcbjUaTySSKouVyqWnabDZzHEfTtJfv8qMAAEKI7/vn8zmKojRNfd/v
9XqMsUqlUgq/rpRlGSFkWVaz2TwcDsfjUQihKIrneYZhKIrySUeWZQihbduDwUBVVYwxxlgI8fPz
02636/U6hJ+8AWNMkqTH43G9Xm+3GyEkjuOiKBzH8TzPdV3DMH598F0SzjmlNMsyzrmmaaZpfgt/
2N/dKsP7LtMbfwB0IOuL0Nd+lgAAAABJRU5ErkJggg==

If you copy and paste the text above to a browser on desktop/PC, the browser is able to render the image with no issues; however, the same behavior is not observed on mobile browsers.

This is the same with Firefox (nightly and regular), along with chrome.

Nov 15 '25 23:11 mrwm

An alternative to getting the Base64 string to render is to link it to a website that can decode base64 files:

Something like website.url?input=data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA8AAA...

but that kinda defeats one of the benefits of QRshare:

Being able to share text without the need of a middleman.
- eg: sending links thru a chat app, bluetooth pairing, or something else.

On the other hand, it's also another story to figure out how to render the Base64 data with all the different file types.

eg: application/pdf, or video/mp4 is not going to render happy on a html page with an <img> tag

That is on the assumption of ignoring the file size limitation. Unfortunately, I am unable to get anything satisfactory, even with images. The best I found was my 15x15 pixel image with only black + shades + white at around 1/2 kb. Any larger filesize would make the XZing (QR) library unhappy.

Even after considering file size, my attempt at the pdf possible: small.pdf (@ ~980Bytes of blank) was still unable to get it small enough to get it to fit within the constraints of the XZing library after Base64 conversion.

Possible alternatives, that I'm not exactly willing on implementing:

Use a different code format aside from QR - This would kinda move it beyond the scope of "QR" sharing: Making it not as universal anymore, as phone cameras typically only support QR codes
Split the data to multiple QR codes - This would then require a counterpart app that users will need to separately install just to re-combine the data: Making it not universal anymore.

Nov 16 '25 01:11 mrwm

hello, because i am also interested in this, there are so called animated QR transfer codes like https://github.com/divan/txqr / https://divan.dev/posts/animatedqr/ or https://cimbar.org/ where there are (graphical) codes as video which then can enhance the bandwidth of transmitting the data. You could even add reed solomon code encoding, so you could account for transfer errors..

there's no official standard, but it would be great if you add this to your app.

Nov 21 '25 14:11 deknos

there's also https://play.google.com/store/apps/details?id=cc.methyl.animated_qr&hl=en which does this, but i do not think it is opensource

Nov 21 '25 14:11 deknos

Hmmm... the more I read up about it, the more I'm being disincentivized to try implementing file transfer with QR codes.

Here are the goals of my project:

Be as lightweight as possible in file size
Be simple both in code and functionality

I'm happy that there are ways to transfer files with QR codes. However, there's a tipping point between a "wow"-factor and a utilitarian standpoint of usefulness.

If users need to (1) search and (2) download my app to receive a file, that will be already two steps in the process needed for file transfer. The friction for users to download an app is already a huge hurtle, and that defeats my goal of keeping it simple if users need an app to decode something only my app can read.

^{^{Alternatively, I can create a new separate app dedicated for decoding QR codes... 🤔}}

...Back to the topic of getting the file out.

I tried the animated QR code app (cc.methyl.animated_qr), but it takes a super long time for it to encode anything larger than 300kb. I don't want my app experience to be the same.

Encoding my v1.0.21 apk at ~800KB took 17s to convert and show 1264 QR codes at 1 frame per second. That took a little over 21 minutes just to send an apk that's not even 1MB! At this point, it is around ~633Bytes per QR code.

Here are some other alternatives as opposed to QR codes:

There's already more superior methods of file transfer out there: Local Send, KDE connect, Syncthing (if convenient)
Alternatively, there's also Bluetooth: That should also be universal (but also has its own friction)
Then there's the wonderful world of USB-C cables... assuming people carry their own cables for charging, etc.

In the end, my reasons against file transfer is because:

Splitting the file to multiple QR codes break the universalness of the app, requiring a decoding part.

I'm open to an alternative where it's a new app for decoding and sending, though.

Nov 22 '25 04:11 mrwm

The cimbar project (https://github.com/sz3/libcimbar) apparently has apparently 100 kb/s, that would be a bit better.

That being said, i understand your position, but i think it's very valuable to have a tool which only needs a screen and a camera for exchanging data. You do not need network or external storage which can be snooped on but i agree it's an edge case.

and there is already an app, but it can only encode (or decode?). Sadly there's no app, which does both, like, which encodes binary data from the smartphone and the same app on another phone can "download" the data via camera and decode.

And especially with cimbar (100kb/s) this would be nice to at least exchange arbitrary length enough data, so you can either exchange keys (which will get bigger, thanks to the postquantum cryptography, mceliece keys are 1mb) or data to reach further data.

That being said, i only wrote all this, because you seemed interested :)

Nov 22 '25 09:11 deknos

Thanks for the suggestion! And yes, I was initially interested, but the more I read about it, the more I get disheartened at the realization of the amount of effort needed to implement 👉👈

Part of my ambitious side wants it, but the lazy side of me is winning, haha.

I'm looking at cfc, and seems like there's already a request to encode: https://github.com/sz3/cfc/issues/17

Since there's already a decoder, I would imagine it might be possible to add an encoder in? I'll poke around it, but no promises ;)

edit: oops, I didn't realize you already made a comment there. I'll drop my question there. 👋

Nov 22 '25 09:11 mrwm