Diagnostic guide

Find where a browser transfer is failing

Written by the ADrop maintainers · Reviewed August 16, 2026 · About 8 minutes

“The devices do not connect” can describe four different failures. Start with the last thing that worked. That observation narrows the problem more reliably than repeatedly refreshing both pages.

Stage 1: Can the page reach signaling?

The status in the header should change from Connecting to the local device name. If it does not, the page has not maintained its secure WebSocket. Confirm that ordinary HTTPS access to the site works, then disable content blockers only for a controlled test. A network can allow the HTML page while blocking or timing out WebSockets.

Switching from office or school Wi-Fi to a personal mobile connection is a useful comparison. If signaling works there, the browser and device are probably fine; the original network is filtering the connection. Re-enable your normal protections after the test.

Stage 2: Are the devices eligible to discover each other?

Automatic discovery groups devices by the public network address visible to the server. Both should normally use the same Wi-Fi or the same phone hotspot, and each visibility setting should allow same-network discovery. A VPN can give the two browsers different exits even while they are physically nearby. Conversely, a large managed network may share one exit but isolate clients internally.

Use Add by ID to test discovery separately. Copy the complete ID from the other device's Settings while that page is online. If the lookup succeeds but the card never appeared automatically, discovery scope or visibility was the issue. If lookup says the device is unavailable, check for a mistyped ID, Hidden visibility, a closed page, or a dropped signaling connection.

Stage 3: Did the invitation reach the receiver?

If the receiver sees the file list and approval prompt, discovery and signaling are working. A failure after Accept is therefore not fixed by changing the device name or retyping its ID. The browsers are failing to establish the direct WebRTC path.

Stage 4: Did bytes begin moving?

Once progress rises above zero, the peer connection and file channel have worked. Stops at this stage usually come from Wi-Fi roaming, a sleeping phone, a suspended background tab, or severe congestion. Keep both pages visible, prevent screen lock, move closer to the access point, and avoid changing between Wi-Fi and cellular data.

ADrop attempts an in-page resume for up to two minutes. Do not refresh during that window. A refresh destroys live transfer state and the sender's permission-backed file reference, turning a recoverable channel interruption into a restart.

Stage 5: Was the file received but not saved?

A save picker that was cancelled is different from a network error. Accept again and choose a writable location. If the browser uses private storage, it needs enough quota for the incoming file plus working room. On a memory fallback, a file can exceed practical memory even when the device has free disk space. For large files, a desktop Chromium browser with a direct destination picker is the safest supported route.

What information makes a bug report useful?

Record the two device types, browser names and versions, network type, the last visible stage, approximate file size, and exact error text. Do not send the file, its private name, a full device ID, local IP addresses, or screenshots containing sensitive filenames. A report that says “the receiver accepted, then direct connection timed out on office guest Wi-Fi” already isolates the failure far better than “it doesn't work.”

This guide maps each symptom to the actual ADrop connection state machine. It does not assume that every network permits peer-to-peer traffic.