A WebRTC JavaScript example is a working pattern for connecting two browsers directly for video, audio, or data exchange. It combines three browser APIs: getUserMedia for camera and microphone access, RTCPeerConnection for the peer-to-peer media link, and a signaling channel you supply for exchanging connection data. VideoSDK builds on this same foundation, wrapping the handshake, TURN fallback, and room management into a JavaScript SDK so you ship calls in minutes instead of weeks. This guide walks you through the entire flow in plain language, no code required, and shows you what it takes to move from a toy example to production.
Every year, thousands of developers search for a working WebRTC JavaScript example, and most of them hit the same wall. The browser APIs look simple on the surface, but the moment you try to connect two people across different networks, you run into NAT traversal, signaling, and a handshake protocol that is easy to describe and painful to wire up by hand.
The good news is that the underlying flow is genuinely learnable in one sitting. WebRTC gives you three core APIs: one to capture media, one to negotiate a direct connection, and one (the data channel) to send arbitrary messages once that connection exists. The part browsers deliberately leave out is signaling, the channel where the two peers exchange the information needed to find each other.
By the end of this walkthrough, you will understand every step of a WebRTC JavaScript example, from capturing your first video frame to exchanging ICE candidates, plus what changes when you move from a learning prototype to a production deployment.
What is WebRTC and How Does It Work in JavaScript?
WebRTC is defined as a collection of standardized browser APIs and transport protocols that enable real-time audio, video, and data exchange between browsers and devices without requiring plugins or intermediate media servers for the basic peer-to-peer case. In JavaScript, it surfaces through a small set of objects, most importantly the media capture interface and the peer connection object.
WebRTC works by letting each browser first capture local media, then negotiate a direct, encrypted connection with a remote peer using the offer/answer model, and finally stream media over that connection using SRTP, the secure real-time transport protocol. The negotiation data travels over your own signaling channel; the media itself travels peer to peer whenever the network allows it.
The three pieces you touch in almost every WebRTC JavaScript example are the media devices interface for requesting camera and microphone access, the peer connection object for managing the session, and the data channel interface for sending structured messages like chat text or game state.
Real-world use cases built on this foundation include one-to-one video chat, multi-party conferencing (where a media server joins the mix), live streaming, remote device control, and file transfer. If you would rather skip the low-level plumbing entirely, VideoSDK's JavaScript video calling SDK implements the entire pattern for you, including the signaling layer and TURN fallback.
The Three-Step Handshake Explained
Every WebRTC connection follows the same three-step handshake, and understanding it is the single most valuable thing you can take away from any WebRTC JavaScript example.
Step 1: Offer creation. The initiating peer captures its local media, creates a peer connection, and generates an offer. The offer is a session description, formatted as SDP, that lists the media the initiator wants to send, the codecs it supports, and its preliminary network candidates. The initiator sets this description as its local description and sends it to the other side over the signaling channel.
Step 2: Answer generation. The receiving peer gets the offer, creates its own peer connection, adds its local media tracks, and generates an answer. The answer is another SDP blob that confirms which codecs and media the receiver accepts. It travels back to the initiator over the same signaling channel, and both peers now agree on what the session will contain.
Step 3: ICE candidate exchange and connection finalization. With the offer and answer in place, both peers begin gathering ICE candidates, which are possible network routes for reaching each other, including local addresses, public addresses discovered via STUN, and relayed addresses provided by TURN. Candidates are exchanged as they are discovered, and the ICE agent on each side probes the routes until it finds one that works. Once a viable pair is confirmed, the connection state changes to connected and media begins flowing.
The order matters: offer first, answer second, candidates throughout. Swapping the order or dropping candidates is the most common reason a first WebRTC JavaScript example silently fails to connect.
Choosing a Signaling Method for Your WebRTC JavaScript Example
Signaling is the one part of WebRTC the browser does not provide, which means every WebRTC JavaScript example needs you to make a deliberate choice about how peers exchange offers, answers, and candidates.
Manual copy-paste. For learning, you literally paste the SDP text from one browser into the other. It is slow, clunky, and only works for one connection at a time, but it makes the handshake visible and forces you to understand what is actually being exchanged. For a minimal first example, this is the approach I recommend.
WebSocket server. A small server relays messages between peers in real time. This is the standard production choice: low latency, full duplex, and easy to secure with token-based authentication. The trade-off is that you now own a server component and its scaling story.
Firebase or similar realtime database. Peers write signaling messages to a shared database location and listen for changes. This gets you working signaling with almost no server code, at the cost of a third-party dependency and per-message pricing at scale.
HTTP polling. Peers periodically request pending messages from a server. It works, but the polling interval adds latency to the handshake and it is the least efficient option. Avoid it except in constrained environments.
For your first WebRTC JavaScript example, use manual exchange. Once the flow works, graduate to WebSockets or a managed service. VideoSDK eliminates this decision entirely by providing the signaling layer as part of its room-based architecture.
Setting Up Media Capture with getUserMedia
Media capture is where every WebRTC JavaScript example begins, and it is the first place browsers enforce user trust.
The browser exposes camera and microphone access through the media devices interface. When your page requests media, the browser prompts the user for permission. Until the user grants it, your code receives nothing, and if the user denies it, you get an error you must handle gracefully rather than letting the page break.
Handle denials by showing a clear message explaining why the permission is needed, and offer an audio-only fallback if the camera is unavailable. On laptops with privacy shutters, a black video frame is often a physical shutter issue rather than a bug, which is worth remembering before you spend an hour debugging.
When requesting video, you can express constraints such as preferred resolution and frame rate. A sensible default for video chat is high-definition resolution at a moderate frame rate, which balances quality against bandwidth. Requesting maximum resolution on every device wastes bandwidth on mobile connections and can cause the encoder to struggle on low-end hardware. Always treat your requested constraints as preferences, not guarantees, since the browser delivers the closest match the device supports.
One more thing that bites people here: media capture requires a secure context. On localhost it works in most browsers, but in production your page must be served over HTTPS or the media APIs simply will not exist.
Building the Peer Connection with RTCPeerConnection
The peer connection object is the heart of any WebRTC JavaScript example, managing negotiation, media transport, and connection state in one place.
Creating the connection. You construct a peer connection and supply it with a list of ICE servers, typically at least one STUN server so peers behind NAT can discover their public address. For reliability across strict firewalls and corporate networks, you also configure a TURN server, which relays media when no direct route can be found. Google operates a public STUN server commonly used in examples, but production deployments should use dedicated infrastructure or a managed provider.
Adding local tracks. Once media capture succeeds, you attach each local audio and video track to the connection. This is what tells the negotiation layer which media to advertise in the SDP offer.
Receiving remote tracks. When the remote peer's media starts arriving, the connection raises a track event for each remote track. You respond by attaching each track to a video or audio element on the page so the user can see and hear the remote peer. This event-driven pattern means you never manually pull media; you react to what arrives.
Watching connection state. The connection exposes state changes across its lifecycle: new, connecting, connected, disconnected, and failed. A production-quality example listens for these transitions, showing a spinner during connecting, surfacing a reconnect attempt on disconnected, and triggering an ICE restart on failed. Ignoring these states is why so many demo apps work perfectly on the developer's machine and fall apart on real networks.
The diagram above shows the full architecture of a two-browser example: media capture on each side, peer connections configured with STUN and TURN, a signaling bridge carrying only negotiation data, and encrypted media flowing directly between peers once the handshake completes.
Exchanging Signaling Data Without a Server
For a first WebRTC JavaScript example, the manual copy-paste workflow is worth doing at least once because it makes the invisible negotiation visible.
The workflow works like this. The initiator creates the offer, which the browser represents as a structured description object. You convert it to a text form, typically by serializing it as JSON, and paste it into a text box on the receiving side. The receiver feeds that text back into its peer connection, which triggers answer generation. The receiver then serializes its answer and pastes it back to the initiator, who applies it as the remote description.
ICE candidates are gathered continuously during this process, and each one also needs to travel to the other side. In the manual workflow, you wait for candidate gathering to complete, bundle all candidates with the description, and paste the combined payload once, which avoids the ordering headaches of pasting candidates one at a time.
Ordering is everything. The offer must be applied before the answer is generated, and remote candidates should only be added after the remote description is set. If you add candidates before the remote description exists, the browser will reject them unless you queue them yourself. This ordering requirement is invisible in server-based examples because the server handles sequencing, which is exactly why the manual exercise teaches you something a polished demo hides.
Common Pitfalls and Debugging Tips
Most failed WebRTC JavaScript examples fail for one of a small set of reasons, and knowing them saves entire evenings.
NAT and firewall traversal. Direct peer-to-peer connections fail whenever both peers sit behind strict NATs or corporate firewalls that block UDP. The fix is a TURN server, which relays media when no direct route exists. If your example works on the same network but never across networks, missing TURN is almost always the cause.
Browser compatibility quirks. Chrome, Firefox, and Safari all implement the standard, but differ in codec preferences, autoplay policies, and how they surface track events. Safari in particular requires user interaction before playing remote audio in some configurations, and its autoplay rules are stricter than Chrome's. Test on Safari early if your audience includes iOS users.
Permission denials and device errors. A denied permission, a missing camera, or a device claimed by another application all surface as errors at capture time. Handle each case with a distinct user-facing message instead of a generic failure, and always provide an audio-only path when video capture fails.
Inspecting with browser dev tools. Chrome's internal WebRTC internals page shows every ICE candidate, the selected candidate pair, and the transport state in real time. When a connection stalls, this is the first place to look: it tells you whether the failure is in gathering candidates, probing them, or applying the remote description. The browser console also logs negotiation warnings that point directly at ordering mistakes.
Scaling Up: From Example to Production
A working WebRTC JavaScript example is a milestone, not a product. Three things change on the road to production.
First, replace manual signaling with a WebSocket server or a managed realtime service. Your signaling layer should authenticate users with short-lived tokens, scope each session to a room, and reject unauthorized participants. Never run open signaling in production.
Second, add TURN infrastructure. Public STUN servers are fine for learning, but production connectivity across mobile carriers and corporate networks requires TURN with proper capacity planning, since relayed media consumes bandwidth on the relay. Managed providers bill by relayed gigabyte, so estimate usage before committing.
Third, secure everything. HTTPS is mandatory for media capture. Token-based room access control prevents link-sharing attacks. And if your use case demands it, end-to-end encryption keeps media opaque even to the infrastructure in the middle.
This is precisely the point where most teams evaluate build-versus-buy. VideoSDK handles all three production concerns out of the box: managed signaling, TURN infrastructure, token-based authentication, plus recording, transcription, and adaptive streaming. The Prebuilt UI Kit gets a working video call into your app with no custom UI at all, and the REST APIs let your backend create rooms and manage sessions programmatically.
Definitions Glossary
WebRTC: A standardized set of browser APIs and protocols enabling real-time audio, video, and data exchange between peers, with media flowing directly between browsers whenever the network allows it.
SDP: Session Description Protocol, the text format used to describe a media session, listing codecs, media types, and transport parameters in the offer and answer exchanged during negotiation.
ICE: Interactive Connectivity Establishment, the framework that gathers candidate network routes and probes them in pairs until a working path between two peers is confirmed.
STUN/TURN: STUN lets a peer discover its public network address behind NAT; TURN relays media through a server when no direct route can be established, guaranteeing connectivity at the cost of added latency and bandwidth.
Signaling: The developer-supplied channel over which peers exchange offers, answers, and ICE candidates before media flows; WebRTC deliberately leaves this layer unspecified, so every implementation chooses its own transport.
Key Takeaways
- Every WebRTC JavaScript example follows the same three-step handshake: offer creation, answer generation, and ICE candidate exchange, in that strict order.
- The browser provides media capture and the peer connection, but you must supply the signaling channel yourself, whether by copy-paste, WebSocket, or a managed service.
- TURN infrastructure is what separates a demo that works on your machine from a product that works behind corporate firewalls and mobile carriers.
- Media capture requires HTTPS in production, and permission denials need graceful handling with audio-only fallbacks.
- When you are ready to skip the plumbing, VideoSDK's JavaScript SDK and Prebuilt UI Kit deliver the entire pattern, signaling, TURN, and room management included, so you can ship real video calls in minutes.
Conclusion
A WebRTC JavaScript example teaches you the offer/answer handshake, ICE candidate exchange, and the realities of NAT traversal, knowledge that transfers directly to any real-time communication project you will ever build. The raw APIs are a superb education and a demanding production path, which is why most teams eventually hand the plumbing to a platform. If you want to see how much of this flow disappears behind a clean SDK, start with the VideoSDK JavaScript quickstart, grab the free tier at app.videosdk.live/login, and explore the code samples for working reference apps. What are you building with WebRTC or VideoSDK? Drop a comment, I'd love to hear what kind of real-time use case you are working on.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ