SQL Server Deadlock XML Viewer

Open an .xdl file or paste a SQL Server deadlock report and see the victim, the processes, the locked resources and the owner/waiter edges as a graph with the execution stacks and input buffers next to it. Works on Mac, Windows and Linux. The XML is parsed in your browser; nothing is uploaded.

Report file .xdl or .xml, up to 10 MiB. Binary .xel files are not readable here.

Or paste the deadlock XML

Pick a file, paste a report or click Load sample. The graph, the incident list for multi-incident reports and the details pane appear here.

What a SQL Server deadlock graph shows

When two or more sessions each hold a lock the other needs, none of them can finish. SQL Server's lock monitor detects the cycle, rolls back one session (the victim, error 1205) and writes a deadlock report: an XML document with a <victim-list>, a <process-list> (one <process> per session or parallel worker, with its execution stack and input buffer) and a <resource-list> (one element per lock — keylock, pagelock, objectlock and others — each listing its <owner> and <waiter> processes with lock modes). SSMS saves this as an .xdl file.

The viewer draws that report as a two-column graph: processes on the left, resources on the right. A solid edge from a resource to a process means the process owns the lock in the given mode; a dashed edge from a process to a resource means the process requests it. The victim carries a red badge and its request edge is red. Graph identities are the report's process ids (for example process24ab8c8), not SPIDs, because parallel workers of one query share a SPID and differ only by ECID.

Example: two processes, two key locks

The built-in sample (click Load sample above). SPID 62 runs usp_ReserveStock: it owns a U lock on a key of SalesDb.dbo.Inventory and requests a U lock on a key of SalesDb.dbo.Orders. SPID 71 runs usp_ShipOrder: it owns the X lock on that Orders key and requests an X lock on the Inventory key. Each waits for the other, so SQL Server rolls back SPID 62 — the process that had written less transaction log (logused="312" against 1164). The two procedures touch the same tables in opposite order; making the access order consistent is the usual fix. The sample is synthetic: object names, hosts and logins are invented.

Supported formats and limits

Wrappers: a bare <deadlock> (the .xdl SSMS saves), a <deadlock-list> with several incidents (trace flag 1222 style), a single Extended Events <event name="xml_deadlock_report">, and <RingBufferTarget> / <events> exports with many events. Multi-incident reports get an incident list with the event timestamp, the victim and the process/resource counts.
Encodings: UTF-8 with or without a byte-order mark, UTF-16 LE and UTF-16 BE (detected from the BOM or the leading < code unit).
Size: 10 MiB per file or paste, at most 64 nesting levels, 250,000 XML elements and 500 incidents. Larger input is rejected with a message; nothing is silently cut.
Not supported: .xel is the binary Extended Events file format, not XML — export the events as XML/XDL first, or read them from the server with the desktop app. Documents that declare a DTD or entities (<!DOCTYPE>, <!ENTITY>) are rejected before parsing; external resources are never fetched.

Everything stays in your browser

The page loads one script that contains the same parser the Jam SQL Studio desktop app uses. Your file or paste is read by that script, parsed in memory and rendered as text and SVG. It is not sent to any server, not placed in the URL, and not written to localStorage or sessionStorage. Analytics record only that a parse succeeded and an incident-count bucket — never the XML, SQL text or file name. Clear drops the report from memory.

Limitations

The graph proves what SQL Server wrote: who owned and who requested which lock in which mode when the deadlock monitor ran. It does not prove why the statements ran in that order or that any change is safe.
Resource kinds that are not lock resources — exchangeEvent (parallelism), threadpool and unrecognised elements — are drawn with a dashed border and a Partial badge. Their owner/waiter entries and attributes are shown verbatim; no blocking relationship is derived from them.
Missing optional fields (no victim, a resource without an id, an owner that is not in the process list) are listed as warnings in the overview, not filled in with guesses.
The browser viewer reads files and pasted text only. Collecting incidents from a live server is done by the desktop app.

Frequently asked questions

Can I open an XDL file on Mac?

Yes. An .xdl file is plain XML, so this page opens it in any current browser on macOS, Windows or Linux: pick the file or paste its contents. SQL Server Management Studio is Windows-only, but the report itself is not. For files from your own server, the Jam SQL Studio desktop app opens .xdl and .xml reports on all three operating systems.

Does this upload my deadlock XML?

No. The file or pasted text is parsed by JavaScript running in your browser and kept in memory only. It is not sent to a server, not put in the URL, and not written to local or session storage. Analytics record that a parse succeeded and an incident-count bucket, never the XML, SQL text or file name. Clear drops the report from memory.

What is the victim in a deadlock graph?

The victim is the process SQL Server chose to roll back so the other participants could continue. It is recorded in the report's victim-list and marked with a red Victim badge in the graph. By default SQL Server picks the process that is cheapest to roll back (least transaction log used) unless a session raised its DEADLOCK_PRIORITY.

Can this fix the deadlock automatically?

No. The viewer shows what the report proves: which process held or requested which lock, in what mode, and which process was chosen as the victim. It does not generate corrective SQL or claim a root cause. Use the execution stacks and input buffers to find the statements, then decide on access order, transaction scope, index or isolation-level changes yourself.

How do I get deadlock reports from my server?

SQL Server and Azure SQL Managed Instance record every deadlock as an xml_deadlock_report event in the built-in system_health Extended Events session; export the events as XML or .xdl (for example from SSMS's Extended Events viewer) and open them here. Azure SQL Database has no system_health session, so you need your own Extended Events session that captures xml_deadlock_report. Jam SQL Studio's desktop Deadlock Analyzer opens the same files and can read the retained system_health events directly from a connected server.