qrdrop

Scan a code, send a file, device to device. Nothing in between ever holds a readable copy.

What this does and does not protect

Files are encrypted end to end under a key derived from the QR code, on top of WebRTC's own encryption. Relays and TURN servers see ciphertext and byte counts, never contents.
Each transfer uses fresh keys. A code captured later cannot decrypt a transfer that already happened.
Anyone with the code can join. It is the entire credential. Show the QR to the person you mean to send to, and not to a room.
Both devices learn each other's IP address. That is inherent to a direct connection.
Code is self-hosted, not loaded from a CDN. This page serves a bundle built from source, so the jsDelivr risk that used to be listed here is gone. What remains: the server hosting this page could still serve modified code, the same way any web app's server could. No in-browser design prevents that. For genuinely sensitive material, use a tool you can verify before running.
The QR code can encode a link, and that link still keeps the key off the wire. Scanning it with a phone's own camera app opens this page with the key in the URL's fragment -- the part after #. A fragment is never sent to a server as part of the HTTP request; the browser keeps it local and hands it to this page's own script. So yes, you should be wary of a link containing what looks like a key -- that instinct is correct in general -- but here the fragment is exactly what stops it from leaving your device, the same guarantee the plain qrdrop: code has always had.