Building a Peer-to-Peer Clipboard Sync System with WebRTC

A few months ago, I noticed a small but annoying workflow problem.

I was constantly moving small pieces of information between devices.

A code snippet from my laptop to my phone.

A URL from one browser to another.

A temporary note that I needed somewhere else.

The amount of data was never the problem. The problem was the unnecessary friction.

Most clipboard synchronization tools solve this problem by introducing a cloud service:

Device A
    |
    |
    v
Cloud Server
    |
    |
    v
Device B

This approach is simple and reliable, but it also means clipboard content leaves your devices.

For many cases, that may be acceptable. But clipboard data can contain sensitive information:

• Passwords
• Authentication codes
• Private messages
• Source code
• Temporary documents

Clipboard content is usually short-lived. It exists for seconds or minutes and then disappears.

This raised an interesting question:

Can we synchronize clipboard content directly between devices without sending it to a server?

The answer is yes, using WebRTC DataChannels.

The architecture

The basic idea is simple:

             Signaling Server

          Exchange connection data

Device A  -------------------- Device B

             WebRTC DataChannel

          Direct peer-to-peer data

The signaling server is only responsible for helping devices discover each other.

It exchanges:

• Session descriptions
• ICE candidates
• Connection information

After the connection is established, clipboard data travels directly between peers.

The data flow changes from:

Copy
 |
Upload
 |
Store on server
 |
Download
 |
Paste

to:

Copy
 |
Create message
 |
WebRTC DataChannel
 |
Receive
 |
Update clipboard

Why WebRTC DataChannel?

WebRTC is mostly known for video calls and real-time communication.

However, the most interesting part for this use case is DataChannel.

DataChannel allows browsers to exchange arbitrary data directly between peers.

It provides:

• Low latency communication
• Peer-to-peer transport
• Encrypted communication
• Support for text and binary data

Clipboard synchronization does not require huge bandwidth.

A clipboard update is usually just a small message:

{
  "type": "clipboard",
  "content": "Hello from another device",
  "timestamp": 1720000000
}

There is no reason to upload this tiny piece of data to a central storage system.

Detecting clipboard changes

The first challenge is clipboard monitoring.

Modern browsers provide the Clipboard API:

const text = await navigator.clipboard.readText();

console.log(text);

However, clipboard access is intentionally restricted.

Browsers do this because unrestricted clipboard access would create serious security problems.

A malicious website could silently read:

• Passwords copied from password managers
• One-time authentication codes
• Private conversations

Therefore, applications need proper permissions and user interaction.

A simplified clipboard reader:

async function getClipboardContent() {
    const content = await navigator.clipboard.readText();

    return {
        type: "clipboard",
        content
    };
}

Once new content is detected, it can be sent through the WebRTC connection.

Sending clipboard data through WebRTC

Creating a DataChannel is straightforward:

const channel =
    peerConnection.createDataChannel(
        "clipboard"
    );

channel.onopen = () => {
    console.log("Connected");
};

Sending clipboard content:

channel.send(
    JSON.stringify({
        type: "clipboard",
        content: text
    })
);

Receiving data:

channel.onmessage = event => {

    const message =
        JSON.parse(event.data);

    if(message.type === "clipboard") {
        navigator.clipboard.writeText(
            message.content
        );
    }
};

The browser does not need to know the physical location of the other device.

WebRTC handles the communication layer.

The difficult part: establishing the connection

The DataChannel itself is simple.

The complicated part is creating the connection.

WebRTC requires:

• SDP negotiation
• ICE candidate exchange
• NAT traversal
• STUN/TURN infrastructure

The connection process looks like:

Device A

Create Offer

      |
      v

Signaling Server

      |
      v

Device B

Create Answer

After both devices exchange connection information, WebRTC attempts to create the best possible network path.

In many home networks, devices can communicate directly.

However, some environments are more complicated:

• Corporate networks
• Strict NAT
• Mobile carrier networks

In those situations, TURN servers may be required as a relay.

Preventing clipboard synchronization loops

A real implementation quickly runs into another problem.

Imagine two devices:

Device A copies:

Hello

The content is sent to Device B.

Device B updates its clipboard.

The clipboard watcher on Device B detects the change.

Now Device B sends the same content back to Device A.

Without protection:

Device A
    |
    v
Device B
    |
    v
Device A
    |
    v
Device B

To prevent this, each clipboard message needs metadata.

Example:

{
  "id": "unique-message-id",
  "source": "device-a",
  "type": "clipboard",
  "content": "Hello"
}

Devices can keep a small history of processed message IDs.

If the same message appears again, it is ignored.

Security considerations

Clipboard synchronization requires careful handling.

A good design should consider:

Avoid permanent storage

Clipboard data should only exist during transmission.

Saving clipboard history introduces unnecessary risk.

Encrypt communication

WebRTC provides encrypted communication channels.

The goal is that clipboard content should only be readable by the connected devices.

Verify connected devices

A user should always know which devices are paired.

A clipboard synchronization tool should never silently connect unknown devices.

Why not use a traditional backend?

A backend API would be easier:

POST /clipboard

GET /clipboard

This design is simple.

But it creates a central point that receives clipboard data.

The trade-off looks like this:

Cloud based approach

Advantages:

• Easier implementation
• Works across networks
• Simple device history

Disadvantages:

• Server receives clipboard data
• Requires storage handling
• Privacy concerns

Peer-to-peer approach

Advantages:

• Data stays between devices
• No temporary cloud storage
• Lower latency

Disadvantages:

• More networking complexity
• Requires WebRTC connection management

For temporary personal data, peer-to-peer communication is an interesting alternative.

Building a real implementation

While exploring this architecture, I built Textunnel, a browser-based tool for moving text, code, and files between devices.

The clipboard synchronization feature follows the same idea: keep your data moving directly between your own devices.

You can try it here:

clipboard sync

Final thoughts

Clipboard synchronization looks like a small feature, but building it properly involves many interesting engineering problems:

• Browser security restrictions
• Real-time communication
• WebRTC networking
• NAT traversal
• Peer-to-peer architecture

WebRTC is often introduced as a technology for video calls.

But DataChannels make it possible to build many other types of applications.

Sometimes the best way to move your data is not through a server.

Sometimes it is directly between the devices that already belong to you.