An internet connection is required. When establishing a connection, the browser’s underlying WebRTC protocol will briefly request stun:stun.l.google.com:19302. This STUN service is used to help devices discover and connect to each other using local network (NAT / private IP) addressing. If both sides have IPv6 connectivity, the connection can be established directly without going through STUN. In other words, WebRTC requires IP connectivity to work. Even with only local network IPs, STUN is still needed to assist with connection establishment. Without this, communication is limited to a single machine (for example, between two different browsers on the same device). The video demonstration shows exactly this scenario: two different browsers on one machine connecting directly.

The LocSend offline version is designed specifically for users who pursue ultimate security and privacy protection. Unlike other instant messaging and file transfer software that submits data to servers (which introduces privacy risks and file size limitations), this offline version sacrifices convenience and allows users to exchange signaling information manually. It achieves truly serverless local execution as an HTML file, ensuring maximum security and reliability.

✅ Signaling exchange site provided: sig.locsend.com (convenient for transferring between computer and mobile)

The signaling data is generated by the browser at a low level and the signaling string is very long, making QR codes practically impossible to scan reliably. In addition, the offline version runs locally via file://, so it cannot access the camera API. At most, it could only open the photo gallery to recognize local images, which is actually less convenient.

✅ A signaling exchange site is provided: sig.locsend.com (convenient for transfers between computers and mobile devices)

You are using the true offline version — pay attention to the word “true”.

The true offline version has no servers involved at all. Signaling must be manually exchanged by both sides, and once the connection is established, there is no automatic reconnection mechanism.

So-called P2P direct connection means that browsers generate connection addresses (ICE candidates) based on the WebRTC protocol.

Even on the same computer with two browsers, they are still treated as two independent nodes establishing a direct P2P channel. Stability therefore depends entirely on the local network, operating system, and browser state.

As a result, if the true offline version disconnects or becomes unstable after about one minute, this is usually not a program bug, but normal behavior of WebRTC without any server-side fallback.

There are only two solutions:

1️⃣ Refresh the page and manually exchange the signaling again

2️⃣ Use the online version — the online version supports automatic reconnection after disconnection and is significantly more stable

The true offline version prioritizes zero servers, zero dependencies, and absolute privacy, not connection stability. This trade-off needs to be understood.

✅ Signaling exchange site provided: sig.locsend.com (convenient for transferring between computer and mobile)

In a pure browser-based environment, automatic LAN discovery relies entirely on the server identifying devices via public IP addresses. This means that anyone within a large LAN environment—such as a campus network, a NAT-shared network, or a corporate network—could potentially join, which introduces significant security risks. LocSend supports direct connections in environments without public IPv4 or with public IPv6. Therefore, by using a temporary room ID and password, you can confidently create your own private transfer environment and ensure transmission security.

The first time you establish a connection, you need to enter the room ID, password, and nickname. After that, the session remains valid for 24 hours. During this period, the browser will automatically reconnect even after a refresh, with no need to re-enter any information.

The official website already provides a video tutorial, and you will see a text prompt once the file transfer is completed.

For large files, after the transfer is completed, there is an additional disk writing process. This process requires patience on both mobile phones and computers. You can first try transferring a small file between 1MB and 100MB to check whether the file size is correct. Then try transferring a large file over 1GB and patiently wait to see whether the final size is correct. On mobile devices, you can pull down to refresh your file directory and observe the file size changing. On Windows systems, you will see a temporary .crswap file. You must wait patiently until this temporary file disappears before opening the transferred file normally. All of this is browser-level behavior. We can only adapt to this process. Please carefully watch the demonstration in the second half of the video tutorial!

In the free online version, temporary room IDs are valid for 24 hours and can be manually revoked in advance. After 24 hours, the room ID will be automatically destroyed.

The first time you establish a connection, you need to enter the room ID, password, and nickname. After that, the session remains valid for 24 hours. During this period, the browser will automatically reconnect even after a refresh, with no need to re-enter any information.

If both parties are on the same local network and use private IPv4 addresses (192.168.x / 10.x / 172.16.x), WebRTC traffic is transmitted directly over the local TCP / UDP network. It does NOT go through the ISP’s public network, does NOT pass through external NAT or WAN routing, and therefore cannot be affected by ISP-level QoS. The speed depends only on the network card, switch, and Wi-Fi quality — equivalent to copying files within a LAN or transferring data to a NAS.

If both parties have public IPv6 connectivity, WebRTC establishes a direct connection using IPv6 addresses, without TURN relays or server forwarding. This traffic does traverse the ISP network (because IPv6 is public), but it is still ordinary point-to-point traffic. There is no “P2P feature server” and no “central node that can be targeted”. From the ISP’s perspective, it is almost indistinguishable from scp / sftp / https downloads.

Conclusion: There is no “special QoS targeting”. At most, ISPs may apply uniform bandwidth policies to all users, but they will not identify or selectively throttle LocSend / WebRTC / P2P tools.

Cloud-drive style transfer and WebRTC-based end-to-end encrypted transmission represent two completely opposite security models.

The design goal of WebRTC is:

Data channels do not pass through any server — browsers establish a direct, encrypted connection with each other.

In an IPv4 local network environment, the data may not even leave the LAN,

which means there is no possibility of third-party inspection, throttling, or retention.

In WebRTC, the role of the server is limited to assisting with the exchange of connection information (signaling).

If you use the online version of LocSend, the server is only responsible for automatically exchanging signaling data.

Once the connection is established, the actual data transfer is a direct communication between your two devices and two browsers.

That’s why the transfer speed often feels very fast —

this is both an inherent advantage of WebRTC direct connections and the result of optimizations specifically made for large file transfers.

Many demo or toy projects do not implement proper flow control or transfer strategies for large files,

so their real-world experience is naturally much worse.

LocSend is a continuously maintained commercial project, not a one-off experimental codebase,

and this positioning was clearly defined from the very beginning.

As for cloud-drive style transfer, its nature is:

Client → Server → Client.

Once a file is uploaded to a server, it is no longer an end-to-end transmission.

Privacy concerns, content inspection, file size limits, and bandwidth restrictions inevitably follow.

For example, WeChat file transfer is essentially a cloud-drive model:

the file is first uploaded to the server, then downloaded by the recipient.

That’s why LocSend will not take the cloud-drive route — please understand this point.

This is not about which approach is better,

but about solving fundamentally different problems.

Regarding whether it is open source, I’d like to briefly share my honest thoughts.

I’m a veteran programmer who was laid off during “optimization,” and I currently don’t have a stable income. I’ve been trying to rebuild a stable life by relying on my own skills. Early on, my projects mainly targeted fellow programmers and followed an open-source route, but the reality wasn’t ideal: licenses were ignored, code was taken directly, projects were copied, and I was even mocked. These experiences were deeply discouraging.

LocSend (locsend.com) is an important transition for me. It no longer targets only programmers, but ordinary users. Precisely because of this, it has given me far more opportunities for recognition and positive feedback.

Therefore, I no longer plan to continue on the open-source path. This decision is based on real-world circumstances and is not a denial of open source itself. In the current environment, open-source licenses are widely ignored, and “free use, copying, and re-skinning” are almost unavoidable. For an individual developer, the cost is simply too high.

I’d also like to say a few words about AI. AI does not automatically give people who can’t code real engineering capability. For veteran programmers like us, AI is just an assistive tool: it helps improve coding efficiency, audit vulnerabilities, and validate ideas, but the core architecture, security boundaries, and overall logic must still be controlled by ourselves. If someone doesn’t even understand the fundamentals or know how to ask the right questions, AI won’t really be able to help.

In the AI era, what I recommend more is: 👉 try collaborating with AI to build something that truly belongs to you.

LocSend is a project born from my own hard work and dedication, so it will not be open source. I hope for your understanding. What I can clearly state is: all features are currently free to use, with no charges of any kind.

Thanks again for your support, and I wish you all the best.