Share files between devices on the same Wi-Fi
OKYASHAREDocumentation

Getting started

Share files between devices on the same Wi-Fi

Understand which Wi-Fi and Ethernet devices can connect and why the same network name is not always enough.

Updated 4 min read

Check the recipient and conversation before sharing. A local network is not proof that every connected device is trusted.

Before you begin

Wi-Fi is a way to reach the local network, not a guarantee of device-to-device access. A wired desktop and a wireless phone can work together when the router permits traffic between them. Two phones showing the same Wi-Fi name may still be isolated on a guest network. Start on a trusted home or office LAN and keep the devices on that network throughout the test.

A practical workflow

Discovery first introduces candidate devices; strict verification then checks a local connection. A common public internet address does not prove that devices are neighbours. Do not disable a firewall globally to make discovery work. If the network owner deliberately blocks peer traffic, ask for an approved network or use another authorised transfer method.

Strict LAN verification

A shared public IP alone is never enough. Without a LAN-node attestation, automatic verification requires a direct connection using local host candidates. A configured LAN node provides a separate device-bound proof of LAN membership.

Questions that matter

How can I send files from my phone to my computer without a cable?

Connect both devices to the same Wi-Fi or reachable wired LAN and open share.okya.app in each browser. After local-network verification, choose a device or room and send your files, up to 1 GB per file. Keep both browsers open. No app or account is needed, and file contents do not go through cloud storage. Guest-network isolation or a VPN can prevent a direct connection.

How does it know that devices are on the same LAN?

In automatic mode, a shared public IP only makes two devices candidates. Share verifies a WebRTC path using local host candidates — private, link-local or mDNS addresses — without STUN or TURN, and re-checks that path while connected. As a separate option, an administrator-run LAN node can attest devices with short-lived signed tokens. For those attested peers, configured STUN and non-relay candidates may be used; TURN relays are always refused.

What happens if my network cannot be verified?

Share shows an explicit message and does not connect you to anyone automatically. Common causes are guest networks with client isolation, VPNs, mobile data, or corporate networks that block peer-to-peer traffic. You can try another network or use an optional LAN verification node.

Open the page. That is the whole setup.

OKYA Share uses only standard browser technology, so there is nothing to install or configure.

  • Join the same network: Connect your devices to the same Wi-Fi or wired LAN, then open share.okya.app in a modern browser.
  • Devices verify each other: A lightweight signaling service introduces candidates. Automatic mode verifies a local host-candidate path; devices attested by a configured LAN node use a separate verification path.
  • Share freely: Once verified, files, messages and screens flow directly between devices. Close the tab to stop sharing.

Connection and privacy

Messages and files are sent over WebRTC DataChannels, which are always encrypted (DTLS). TURN relays are disabled by design, so content can never be forwarded through a server.

If automatic local-path verification fails, Share shows a clear message instead of guessing. An optional administrator-run LAN node can attest devices separately; those attested connections may use configured STUN, but never a TURN relay. Network restrictions can still prevent a connection.

Sources and further reading