Browser P2P transfer

Peer-to-peer file transfer, without installing an app.

Two browsers meet through a temporary room. The signalling service introduces them; the transfer payload is sent over WebRTC and is never stored by FileCarpenter.

Start the transfer

Either way you get a code. Whichever device has a camera scans it.

Choose a file.

Scan this.

Or open the link, or type the name.

—

Enter the code.

Smart Send

Recipient ready.

Checking whether the original file is the best fit.

Recipient capabilities are approximate and temporary.
Original

Original file

Best quality

Technical details

FCShare never changes your original file. Optimization only happens after you choose it.

Save this?

    Transferring

    Moving now.

    0%
    0 B of 0 B —
    —Speed
    ConnectingPath
    EncryptedIn transit

    Delivered.

    No copy was kept anywhere.

    Stopped.

    Ready
    Room—
    Route—
    Payload—
    The short answer

    What peer-to-peer means in this tool

    The server is used to match a room and exchange the connection information WebRTC needs. It does not receive the selected file, build a download page, or retain a transfer history. Once the connection is ready, the file is divided into ordered chunks and sent through the browser data channel.

    Networks do not always permit a direct path. When the operator configures TURN and the browsers cannot connect directly, encrypted traffic may be relayed so the transfer can complete. A relay carries packets but does not turn the session into stored cloud sharing.

    How to do it

    Three steps, in the browser.

    1. 1

      Open a temporary room

      Either the sender or receiver can create it, so the device with a camera can do the scanning.

    2. 2

      Establish WebRTC

      The browsers exchange encrypted connection details through the signalling service.

    3. 3

      Transfer and close

      Files move over the live data channel; closing the room ends access.

    Best for

    • Privacy-conscious one-time sharing
    • People on different platforms
    • Live remote delivery
    • No-install environments

    What stays intact

    • Payload out of server storage
    • A temporary room
    • Encrypted transport
    • Visible connection route

    Know before sending

    • Metadata needed for signalling
    • TURN may relay encrypted traffic
    • No offline recipient link
    • Interrupted transfers do not resume

    Direct, local, and relayed routes

    The status area reports the route the browsers negotiated. “Local network” means both endpoints found a local path. “Direct” means a non-relayed internet path. “Relayed (TURN)” means a relay was required by network restrictions; the file is still encrypted in transit and not stored.

    Room passwords

    An optional room password is derived into a token in the browser with PBKDF2. The plaintext password is not sent to the signalling server. The password controls who can join; WebRTC transport encryption is used with or without it.

    Questions people ask

    Is this the same as uploading to a temporary server?

    No. There is no completed server-side file waiting for the recipient. The sender must remain connected while bytes move.

    Can FileCarpenter read the file?

    The application server does not receive the file payload. As with any web app, use the served code and deployment you trust, and use HTTPS in production.

    Why might TURN be needed?

    Some corporate, carrier, or restrictive NAT configurations block a direct WebRTC path. TURN supplies a compatibility route for encrypted traffic.