Inputs
Example
Paste EDID hex from the exact point in the HDMI chain and inspect timing/Y420, audio/speakers, HDMI transport, HDR, DisplayID, checksums, and byte provenance.
HDMI EDID Decoder
Decode EDID hex or local files into trust-qualified timing, YCbCr 4:2:0, audio, speaker, HDMI transport, HDR, DisplayID, checksum, and byte-provenance evidence.
Useful when an HDMI chain, AVR, matrix, capture card, or display reports capabilities that do not match reality.
What a display really tells the source
Every HDMI handshake starts with the sink handing the source an EDID: a compact binary self-description containing declared timings, audio format codes, static HDR metadata, and identity data. When a setup falls back to 1080p, loses an audio format, or loses HDR after a chain change, the relevant evidence may be in the blob the source received. That blob may not be the display's own: AVRs, matrices, splitters, and EDID emulators can merge, limit, or replace it.
This decoder accepts strict EDID hex or a local binary or text file and builds one evidence-first report. It covers EDID 1.3/1.4 base data, registered CTA video modes, full Short Audio Descriptor occurrences, three distinct speaker maps, HDMI VSDB context, supported HDMI Forum SCDS transport fields such as FRL, DSC, VRR, ALLM, QMS and FVA, qualified static and dynamic HDR records, Dolby Video, HDR10+, SBTM, and supported DisplayID 1.3 and 2.x sections. Unsupported, malformed, truncated, conflicting, or checksum-untrusted data stays explicitly marked with byte provenance instead of becoming an affirmative capability claim.
Decoding the blob from the right point in the chain
Capture the EDID at the exact point you are troubleshooting — from the display itself, from the AVR's output, from behind the matrix — because every device in the chain may present a different one, and decoding the wrong blob answers the wrong question. Check identity and checksums first: a vendor string that does not match the display, or a failing checksum, tells you immediately that you are looking at an emulator, an override, or corruption.
Then read the structured evidence in order: conformance findings, advertised video modes, every audio descriptor occurrence, speaker and room maps, HDMI transport, HDR, DisplayID, and finally coverage and raw byte evidence. The renderer distinguishes encoded JOC or codec-dependent flags from broad proprietary playback claims, keeps static and dynamic HDR separate, and shows negative or malformed fields instead of silently upgrading them. Decode captures one at a time and compare the exported share-safe summaries manually if needed; built-in side-by-side comparison, source-mode choice, and signal-chain feasibility analysis are not implemented.
Local decoding and its honest limits
The EDID route is intentionally third-party-free and its route policy disables network access; parsing, rendering, clipboard output, and downloads stay local. The on-screen forensic report may show identity and raw evidence. Default JSON, Markdown, clipboard, redacted-hex, and WebMCP results use an explicit share-safe projection that omits identity, topology, filenames, raw values, unknown vendor payloads, and stable fingerprints. Exact original bytes require a separate one-shot sensitive-data confirmation. Side-by-side comparison, source-mode choice, and end-to-end feasibility analysis are not implemented, so the report cannot prove which mode a source will select or whether the full signal chain can carry it. Nothing here writes or modifies an EDID.
Frequently asked questions
What size should EDID data be?
EDID comes in 128-byte blocks: a base block plus optional extension blocks, so 128, 256, or more bytes in complete multiples. The decoder expects whole blocks and verifies each block's checksum.
Why does my AVR show different EDID data than the TV?
Because devices in the chain actively manage EDID: an AVR merges its audio capabilities into the display's video capabilities, and matrices or splitters often present the lowest common denominator or a fixed table. That is normal — and precisely why capture point matters.
Can this tool change or write an EDID?
No. It only decodes what you paste or load — it does not program emulators, flash displays, or set driver overrides. Use it to verify what an override should contain, and to check what one actually contains afterwards.
What does a checksum or trust failure mean?
Each 128-byte EDID block must sum to zero modulo 256, and DisplayID adds its own section framing and checks. A failure can indicate truncation, a copy-paste error, malformed length data, an inconsistent extension count, or genuine corruption. The report retains the evidence but suppresses or qualifies claims that depend on untrusted bytes.
Why is a capability missing even though the display supports it?
The source only sees the EDID it receives, not the display's specification sheet. An intermediate device may strip a declaration, an override may be active, the relevant block may be malformed, or the field may be outside the decoder's pinned public registry. Missing evidence is not proof that hardware lacks the feature.
Does the decoder compare captures or choose a mode?
No. It decodes one active source at a time. It does not compare two EDIDs, model link budgets, account for cable or repeater limits, apply a source's selection policy, or prove end-to-end playback.
Does EDID contain private data, and what is safe to export?
It can carry manufacturer and product identity, manufacture date, serial-like values, HDMI topology, DisplayID identification, and unknown vendor bytes. Default exports and WebMCP omit those fields through an allowlisted share-safe report. Redacted hex is evidence text rather than a loadable EDID; the exact original is available only after a separate one-shot confirmation.