DEV Community: VernonHeim

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

VernonHeim — Mon, 10 Aug 2026 02:32:22 +0000

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.

How WebRTC Enables Fast and Private Peer-to-Peer File Sharing

VernonHeim — Mon, 20 Jul 2026 14:00:28 +0000

Sharing content between devices sounds like a simple problem.
I explored this everyday frustration in more detail in Why Moving Files Between My Own Devices Is Still More Complicated Than It Should Be.

You copy some text on your laptop, open your phone, and realize there is no easy way to move that information. Maybe it is a code snippet, a temporary file, a URL, or a piece of text you need immediately.

Traditional solutions usually rely on cloud storage:

Upload data to a server
Store it temporarily
Download it on another device

This works, but it introduces additional complexity:

Your data needs to travel through third-party servers
Temporary information may be stored longer than expected
Users need accounts and complicated workflows

WebRTC provides another approach: direct peer-to-peer communication.

What is WebRTC?

WebRTC (Web Real-Time Communication) is an open technology that enables browsers and applications to exchange data directly between devices.

Originally designed for real-time communication such as:

Video calls
Audio communication
Screen sharing

WebRTC also supports direct data transfer through the RTCDataChannel API.

This makes it possible to build applications where devices can communicate without sending every piece of data through a centralized server.

How Peer-to-Peer Data Transfer Works

A simplified WebRTC data transfer flow looks like this:

Device A
   |
   | 1. Create connection request
   |
Signaling Server
   |
   | 2. Exchange connection information
   |
Device B
   |
   | 3. Establish direct P2P connection
   |
Encrypted Data Channel

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

After the connection is established, the actual data can flow directly between peers.

Why Peer-to-Peer Sharing Matters

For many everyday tasks, users do not need a full cloud storage system.

Examples:

Sending a code snippet from a desktop to a laptop
Moving a URL from a phone to a computer
Sharing a small document during development
Transferring temporary files between personal devices

In these situations, speed and privacy are often more important than long-term storage.

A peer-to-peer approach provides several advantages.

1. Faster Transfers

When devices communicate directly, data does not need to travel through a large storage infrastructure.

This can reduce latency, especially for users on the same network.

2. Better Privacy

With traditional file sharing:

User → Cloud Server → User Device

The server becomes part of the data path.

With peer-to-peer communication:

User Device → User Device

The communication is more direct.

3. No Account Required

Many temporary sharing scenarios do not need:

User accounts
Password management
Permanent storage

A lightweight connection can solve the problem immediately.

The Challenges of Building WebRTC Applications

Although WebRTC is powerful, building a reliable application requires solving several problems.

NAT Traversal

Most devices are behind routers or firewalls.

To establish connections, WebRTC uses:

ICE (Interactive Connectivity Establishment)
STUN servers
TURN servers when direct connections fail

The goal is to find the best possible communication path.

Connection Management

Real-world networks are unpredictable.

Applications need to handle:

Connection failures
Device switching
Network changes
Browser compatibility

User Experience

A technically correct WebRTC implementation can still fail if the user experience is complicated.

Users usually want:

Open
Connect
Share

Not:

Create an account
Configure settings
Upload files
Manage storage

Building Simpler Cross-Device Experiences

Modern users often work across multiple devices:

Desktop computers
Laptops
Phones
Tablets

The problem is not always file storage.

Sometimes users simply need a temporary bridge between their devices.

This idea inspired us to build Textunnel, a privacy-focused cross-device sharing tool designed for quickly moving text, code, links, and files between devices.

We also shared the story behind this decision, including why we chose a peer-to-peer approach instead of building another traditional cloud storage service in Why We Built a Peer-to-Peer File Sharing Tool Instead of Another Cloud Storage App.

Instead of creating another cloud drive, the goal is to make device-to-device communication simpler.

Taking WebRTC Beyond Theory

I didn't just want to understand WebRTC — I wanted to build something people
could actually use. So I created Textunnel, a
browser-based tool for peer-to-peer file and text sharing.

A few of the specific tools I've built on top of WebRTC:

QR File Transfer Without Internet uses QR codes for signalling, so you can transfer files without any internet connection at all
Bluetooth WebRTC File Transfer Without WiFi combines Bluetooth discovery with WebRTC data channels for local transfers
Share Clipboard Text Across Operating Systems lets you copy text on one device and paste it on another — regardless of OS

Each of these tools uses the same WebRTC fundamentals we covered above, just
optimized for a specific use case.

The Future of Peer-to-Peer Applications

As browsers become more capable, peer-to-peer technologies will continue to create new possibilities:

Decentralized collaboration tools
Private communication platforms
Local-first applications
Real-time developer workflows

WebRTC is not only a technology for video calls. It is a foundation for building faster, more private, and more user-controlled applications.

For developers building the next generation of productivity tools, peer-to-peer communication is worth exploring.
This idea inspired us to build Textunnel...