SDP Inspector

Parse and inspect a WebRTC SDP offer or answer online - free, private, no upload.

An SDP inspector turns a wall of SDP text into something you can actually debug: every media section, codec, ICE candidate and DTLS fingerprint, labelled in plain English. Paste an offer or answer below - it's parsed entirely in your browser, with nothing uploaded.

Nothing you paste here leaves your browser. Parsing is plain text processing done entirely in this tab - Meetrix never receives your SDP, and nothing is saved between visits.

Why use this SDP inspector

Runs in your browser

Parsing is plain text processing done entirely client-side. Your SDP, including any credentials in it, never leaves this tab.

Nothing left unexplained

Every line gets a plain-English label in the annotated view, not just the parts a tool decided to highlight.

Catches real mistakes

Flags missing ICE credentials, missing fingerprints, duplicate mids and undersized ICE credentials - the kind of thing that silently breaks a call.

How to inspect an SDP offer or answer

  1. Paste an SDP offer or answer into the box above, or click Load a sample SDP if you don't have one handy.
  2. Check the summary chips for a quick read on media sections, bundle groups and any warnings.
  3. Open each media section to see its direction, ICE credentials, DTLS fingerprint, codecs and candidates.
  4. Read the warnings panel for anything missing or malformed - each one explains what the problem means.
  5. Switch on the annotated line-by-line view to see what every single line in the file does.
  6. Copy a text summary or download the full parsed result as JSON.

Common SDP problems and fixes

  • No a=candidate lines anywhere: normal for an SDP captured before trickle ICE gathering finishes. If a live connection has none at all, the problem is ICE gathering, not the SDP - check with the WebRTC ICE tester.
  • Missing a=ice-ufrag or a=ice-pwd: ICE has nothing to authenticate connectivity checks with. Check whether they're declared once at the session level (before the first m= line) instead of per media section - that's valid, but easy to miss when reading quickly.
  • Missing a=fingerprint on a DTLS media section: the DTLS handshake has nothing to verify the live certificate against. Every media section using a DTLS transport needs one, either of its own or inherited from the session level.
  • Duplicate mid values: two media sections claiming the same a=mid breaks bundling and track association. This almost always means a bug in whatever generated or hand-edited the SDP.
  • a=group:BUNDLE lists a mid that doesn't exist: the bundle group references a mid no media section actually declares - check for a typo or a media section that got removed without updating the group line.
  • Unknown payload type with no a=rtpmap: every payload type in the m= line's format list needs either an a=rtpmap or to be one of the small set of legacy static types (0 = PCMU, 8 = PCMA, and a few others). Anything else with no rtpmap is an undefined codec.
  • Offer/answer works locally but fails after "SDP munging": hand-editing SDP (to force a codec, change bandwidth, or strip an attribute) is a common technique, but it's easy to break something a spec requires without realizing - paste both the original and the munged version through this tool and compare the warnings.
  • Everything parses clean but the call still doesn't connect: this tool checks the SDP's internal structure, not whether the network path it describes actually works. Once the SDP itself looks correct, verify connectivity with the ICE tester.

Once your SDP checks out, verify ICE and TURN connectivity with the WebRTC ICE tester, or check whether your connection has the bandwidth for the call in the first place with the bandwidth calculator. Not sure it's your camera, mic or speakers rather than signalling? Run the pre-call check instead. For background on how the pieces fit together, see Meetrix's guide to WebRTC architecture, or browse all Meetrix features.

Frequently Asked Questions

Is this SDP inspector free?

Yes. It is free to use, requires no sign-up, and there is nothing to install.

Is my SDP uploaded anywhere?

No. Parsing happens entirely in your browser tab using plain text processing - Meetrix never receives the SDP you paste, and nothing is saved between visits. The only thing that touches the network at all is the optional Load a sample SDP button, which opens a throwaway local connection purely to generate example text to try.

What is SDP?

The Session Description Protocol describes a WebRTC (or SIP) media session in plain text: which codecs are offered, on which ports and transports, the ICE credentials and candidates needed to connect, and the DTLS fingerprint used to secure the connection. Two peers exchange an SDP offer and answer to agree on all of this before media starts flowing.

Where do I get an SDP to paste in?

From your own application (log the value passed to setLocalDescription or setRemoteDescription), from chrome://webrtc-internals on an active call, or from server-side signalling logs. If you just want to see how the tool works, click Load a sample SDP to generate a real one locally.

Why does my SDP have no a=candidate lines?

That's normal for an offer captured right after createOffer()/setLocalDescription(), before trickle ICE gathering finishes. Candidates are usually sent separately as they're discovered, not baked into the initial SDP. If a completed connection genuinely has zero candidates anywhere, see the ICE tester's troubleshooting for why gathering might be failing.

What does a missing a=ice-ufrag or a=ice-pwd mean?

ICE can't authenticate connectivity checks without both. If they're missing from every media section and not declared once at the session level either, this SDP is incomplete and a connection built from it will fail ICE negotiation.

What does a=fingerprint do, and why would it be missing?

It's the SHA hash of the DTLS certificate this side will present during the handshake - the other side checks the live certificate against it to stop tampering. A media section using a DTLS profile (look for DTLS in the m= line's proto field) with no fingerprint at the session or media level has nothing to verify the handshake against.

What does a=setup:actpass mean?

It's the DTLS role this side is offering to play. actpass means either active or passive is fine and the answerer decides; active means this side will start the handshake; passive means it waits for the other side to start. An offer almost always uses actpass.

Can it tell speakers or bandwidth apart?

No - this tool parses session structure and negotiation details (codecs, ICE, DTLS, bundling), not media content or network performance. For bandwidth planning, use the bandwidth calculator instead.

Why do two payload type numbers show the same codec?

Some codecs are negotiated more than once with different settings - for example one payload type for a codec's normal mode and another for its retransmission (rtx) or forward error correction (red/fec) variant. Check each row's fmtp column for what actually differs.

What does a duplicate mid warning mean?

Two media sections in the same SDP declared the same a=mid value. Mids have to be unique - if two sections share one, bundling and track association will behave unpredictably. This usually points to a bug in whatever generated or hand-edited the SDP.

Which browsers are supported?

Every modern browser can paste and parse SDP text here, since that part is just JavaScript string processing. Only Load a sample SDP needs a browser with RTCPeerConnection support: Chrome, Firefox, Edge and Safari (recent versions) all qualify.

Debugging more than one SDP a week? We build WebRTC infrastructure for a living.

From a single failed negotiation to a full self-hosted deployment, Meetrix builds and debugs WebRTC infrastructure. See Meetrix's self-hosted AWS products if you're ready to run your own.

Talk to Us