Compatibility Checker
Choose a dock and a monitor, tell us what you need, and see whether the connection can deliver it — backed by sourced technical specifications.
The Checker evaluates one connection: a specific dock and a specific monitor, against the exact display mode you ask for. It returns FULL (no degradation), PARTIAL (works with a named limitation), INCOMPATIBLE (the primary function fails), or UNKNOWN (the evidence to answer responsibly doesn't exist) — with the specific bottleneck named, never a bare yes/no.
What this checks
Resolution, refresh rate, color format and bit depth determine how much bandwidth your mode requires; the engine compares that against what the dock's output and the monitor's input can actually carry. Protocol name/version and a verified pixel timing are optional — the Checker only uses a timing it can trace to a source (a manufacturer manual, a standards-body table), never a guessed one. Leaving those fields blank lets the engine tell you what it can actually confirm, instead of assuming a number. How the bandwidth figures are worked out — pixel clock, bits per pixel, encoding overhead — is explained in DisplayPort Bandwidth Explained, and you can run the numbers for any mode in the Bandwidth Calculator. The devices and sources the Checker can answer for are listed on Dataset & Evidence Coverage.
What it doesn't know: the Checker evaluates dock ↔ monitor. It does not evaluate whether your laptop's own USB-C port carries a display signal at all — that depends on DisplayPort Alt Mode support at the port level, which is a separate question from anything a dock or monitor can fix. See DisplayPort Alt Mode for how to check that on your specific laptop.
Every specification behind a result is sourced and ranked — standards bodies (VESA, HDMI Forum, USB-IF) first, then technology owners and manufacturers, then reputable technical media, with community-only claims used last and never presented as an official spec. When that evidence doesn't exist for your exact combination, the Checker says UNKNOWN instead of guessing — an honest "we don't know yet" beats an unverified answer. Full detail: Methodology.
This is the output of the same engine the form above calls, for the Dell WD22TB4 dock and the LG 27UL650-W monitor. It is computed when the page is generated from the current dataset, not written by hand — and it is in the page's HTML, so it does not depend on JavaScript.
Request 1 — 3840×2160 @ 60 Hz, RGB 8-bit over DisplayPort
- Devices
- Dell WD22TB4 → LG 27UL650-W
- Request
- 3840×2160 @ 60 Hz, RGB 8-bit, over DisplayPort 1.4
- Timing used
- 533.28 MHz — CVT-RB v1 (derived from the horizontal frequency published by LG) (from the monitor's own timing record) · source: VESA — VESA Coordinated Video Timings (CVT) Standard, Version 1.2 (medium confidence, inferred rather than quoted)
- Calculation
- 533.28 MHz × 24 bits per pixel = 12.799 Gbps required. Available at the dock's DisplayPort output: 25.92 Gbps (payload after encoding overhead).
- Result
- Fully compatible MEDIUM confidence
- Why
- The requested mode needs 12.799 Gbps and the link carries 25.92 Gbps, leaving a margin of 13.121 Gbps. Every requirement that was asked about is met.
- Evidence
-
- DisplayPort 1.4 — max bandwidth (Gbps)
- DisplayPort 1.4 — encoding overhead (%)
- Verified monitor timing (displayport) — pixel clock
The same pair, with the two other requests a visitor is most likely to try next:
-
Request 2 — 3840×2160 @ 60 Hz, RGB 10-bit over DisplayPort
- Devices
- Dell WD22TB4 → LG 27UL650-W
- Request
- 3840×2160 @ 60 Hz, RGB 10-bit, over DisplayPort 1.4
- Timing used
- 533.28 MHz — CVT-RB v1 (derived from the horizontal frequency published by LG) (from the monitor's own timing record) · source: VESA — VESA Coordinated Video Timings (CVT) Standard, Version 1.2 (medium confidence, inferred rather than quoted)
- Calculation
- 533.28 MHz × 30 bits per pixel = 15.998 Gbps required. Available at the dock's DisplayPort output: 25.92 Gbps (payload after encoding overhead).
- Result
- Unknown MEDIUM confidence
- Why
- Maximum color depth not documented for this input.
- Evidence
-
- DisplayPort 1.4 — max bandwidth (Gbps)
- DisplayPort 1.4 — encoding overhead (%)
- Verified monitor timing (displayport) — pixel clock
The bandwidth fits, but the answer is UNKNOWN: no consulted source documents this monitor's maximum color depth. That is an evidence gap on the monitor, not a bandwidth problem — the engine says so instead of assuming 10-bit works.
-
Request 3 — 3840×2160 @ 60 Hz, RGB 8-bit over HDMI 2.0
- Devices
- Dell WD22TB4 → LG 27UL650-W
- Request
- 3840×2160 @ 60 Hz, RGB 8-bit, over HDMI 2.0
- Timing used
- None on file for this monitor, connection and mode.
- Result
- Unknown MEDIUM confidence
- Why
- We don't have a verified timing for this exact mode on this display, so we can't calculate the required bandwidth.
- Evidence
-
- HDMI 2.0 — max bandwidth (Gbps)
- HDMI 2.0 — encoding overhead (%)
Same monitor and mode over HDMI is UNKNOWN because no verified HDMI timing for it is on file. The engine does not borrow the DisplayPort timing: the same 4K60 mode uses a different pixel clock over HDMI on other monitors (see DisplayPort Bandwidth Explained).
Caveat: only the dock and the monitor are evaluated here. Whether the laptop's own USB-C port carries a display signal, the cable, and Power Delivery are not part of this result. See verified cases for more engine outputs, including one that fits by a very thin margin, and Methodology for how each figure is derived.
This is what the Checker can prove today: dock and monitor, against a display mode you specify, with the source shown. It does not evaluate your laptop, cables, Power Delivery/charging, or operating-system behavior yet — see Methodology for where the model is headed.