EDIDCRAFT

EDID Analysis & Generation Tool

Standards-led field guide

Understand EDID from byte 0 to the last extension

Learn what a display advertises, where each capability lives, how timings are represented, and how to tell a structurally valid EDID from a trustworthy one.

EDID 1.4 CTA-861-H DisplayID 2.1a CVT 2.1 DMT Rev. 13
EDID data set 128 × N bytes
00
Base blockIdentity, display parameters, timings
128 B
01
CTA extensionVideo, audio, HDR, vendor data
128 B
Other extensionsDisplayID or another defined type
optional
01

Start here

A capability advertisement, not a command

EDID is data supplied by a display or downstream AV device. A source reads it and chooses a format it believes the complete signal path can support.

1Sink exposes EDIDDisplay, AVR, matrix, extender
DDC / AUXRead capability data
2Source parses itGPU, player, camera
Video linkSelect a signal format
3Sink receives videoTiming, color, audio, metadata
Always first

Base EDID block

A fixed 128-byte EDID 1.x structure containing identity, physical and color characteristics, timing declarations, four 18-byte descriptors, extension count, and checksum.

Common in AV

CTA-861 extension

Adds consumer-video formats, audio, speakers, HDR/colorimetry, YCbCr 4:2:0 signaling, and organization-specific capabilities.

Block based

DisplayID

A flexible VESA data-block framework for detailed display attributes, multiple timing representations, interfaces, tiled displays, adaptive sync, and more.

02

EDID 1.4

The 128-byte base block

The layout is fixed. Select a region to see what it encodes and what usually goes wrong.

Bytes00h–07h

Recognition pattern

EDID header

The base block starts with the fixed sequence below. A different value means the input is not a normal EDID 1.x base block.

00 FF FF FF FF FF FF 00

Check Reject malformed data before interpreting any later field.

54–125

Four 18-byte descriptor slots

If the first two bytes are nonzero, the slot is a Detailed Timing Descriptor. If they are zero, the descriptor tag identifies monitor information.

FCh Product name FDh Range limits FFh Serial text FEh Text FBh Color point FAh More standard timings F9h Color management F8h CVT 3-byte codes F7h Established III

For EDID 1.4, the first descriptor carries the preferred timing; detailed timings precede display descriptors.

7Fh

Checksum math

Each 128-byte EDID block is valid at the checksum level when its unsigned byte sum is zero modulo 256.

(Σ block[0…127]) mod 256 = 0

To generate the final byte:

checksum = (−Σ block[0…126]) & FFh
03

Raster timing

A resolution is not a complete timing

A mode also needs blanking, sync placement, polarity, scan type, and a pixel clock. Two “1920 × 1080 at 60 Hz” timings can differ at the transport level.

Horizontal lineH total
Active pixelsFront porchSyncBack porch
Vertical frameV total
Active linesFront porchSyncBack porch

Progressive approximationpixel clock = H total × V total × frame rate

Explicit

Detailed Timing Descriptor

Stores pixel clock, active and blanking dimensions, sync offsets and widths, image size, borders, flags, and scan characteristics in 18 bytes.

Use when the exact waveform matters.
Catalog

DMT

VESA Display Monitor Timings is a catalog of established timing definitions. A DMT identity refers to a defined set of parameters, not merely width and height.

Useful for known computer-display modes.
Formula

CVT 2.1

VESA’s formula method defines standard CRT-based timing and Reduced Blanking versions 1, 2, and 3 for non-CRT displays.

Inputs become a reproducible complete timing.
Enumerated

CTA VIC / SVD

A Short Video Descriptor advertises a CTA Video Identification Code. The code points to a format defined by CTA-861.

Common for television and AV formats.
04

CTA-861-H

The extension most AV systems depend on

The CTA extension uses tag 02h. Its compact Data Block Collection advertises video, audio, speakers, color/HDR behavior, and vendor-defined capabilities.

Byte 002hCTA tag
Byte 1RevisionStructure revision
Byte 2DTD offsetCollection boundary
Byte 3FlagsFormats + native DTDs
Bytes 4…Data Block CollectionVariable-length tagged blocks
…126DTDs / paddingDetailed timings after collection
Byte 127ChecksumModulo 256
V

Video Data Block

Contains one-byte Short Video Descriptors. Each SVD carries a VIC and, where defined by the encoding, a native-format indication.

A

Audio Data Block

Contains three-byte Short Audio Descriptors describing format, channel count, sample rates, and a format-dependent third byte.

S

Speaker Allocation

Declares speaker-position support. It complements audio formats; it does not replace the channel count encoded in each SAD.

VS

Vendor-Specific Blocks

Begin with an IEEE organization identifier and use that organization’s definition. HDMI Licensing and HDMI Forum blocks are common examples.

HDR

HDR Static Metadata

Advertises EOTF and static-metadata support. Desired-content maximum, frame-average, and minimum luminance bytes are ordered and optional.

420

YCbCr 4:2:0 Blocks

Y420VDB lists formats supported in 4:2:0; Y420CMDB maps 4:2:0 capability to positions in the CTA Video Data Block.

7 6 53-bit block tag
4 3 2 1 05-bit payload length

The first byte of a CTA data block combines its tag and payload length. Extended-tag blocks use the first payload byte as an additional type code.

05

VESA DisplayID 2.1a

A flexible data-block framework

DisplayID describes physical and performance attributes through typed, variable-length data blocks. When DisplayID 2.0 structure is carried as an EDID extension, the extension tag is 70h.

DisplayID sectionversion 20h
Section headerVersion, byte count, use case, extensions
Data blocksTag + revision/flags + payload length + payload
Section checksumImmediately follows section content

What changes from EDID 1.4?

  • Most information is carried in reusable data blocks.
  • A three-byte block header identifies tag, revision/flags, and payload length.
  • Mandatory blocks and ordering depend on how the structure is used.
  • At least one timing is identified and one timing is declared preferred.
  • Fixed-length 128-byte mapping is defined for use as EDID extensions.
20h / 21h

Product & display parameters

Identity, product naming, image size, native format, feature support, chromaticity, luminance, depth, technology, and gamma-related information.

22h

Type VII timing

A detailed timing representation that explicitly carries timing parameters and preferred-mode information.

23h

Type VIII timing

An enumerated timing-code representation for formats defined by a referenced timing standard.

24h / 2Ah

Type IX & X formula timings

Formula-based modes; Type X was added to support multiple CVT 2.1 Reduced Blanking v3 timings.

26h–2Bh

Advanced capabilities

Interface features, stereo, tiled topology, ContainerID, Adaptive-Sync, and related modern display information.

06

Integrity & meaning

Validation happens in layers

A checksum is necessary, but it only proves arithmetic consistency. A strong validator also checks layout, legal values, and relationships between fields.

  1. 1
    Container

    Length is a whole number of 128-byte blocks and stays within implementation limits.

  2. 2
    Block integrity

    Base header is present, every block checksum passes, and extension count matches actual blocks.

  3. 3
    Field structure

    Offsets, lengths, descriptor envelopes, reserved values, and data-block boundaries are legal.

  4. 4
    Cross-field meaning

    Preferred/native flags, timing ranges, color formats, maps, and dependent fields agree.

  5. 5
    System test

    The source, transport path, and sink reliably operate with the advertised format.

Fast structural checklist

Three costly assumptions

“The checksum passes, so the EDID is correct.”

No. A perfectly checksummed block can contain contradictory, reserved, or physically impossible data.

“Preferred” and “native” always mean the same thing.

No. They are related concepts with context-specific signaling. CTA native SVDs and native DTD count are separate from the EDID 1.4 preferred timing.

More advertised modes are always better.

No. Extra modes can change source selection behavior and expose combinations the end-to-end path cannot carry reliably.

07

Apply it in EdidCraft

A safe decode–edit–validate loop

Keep the original, change one capability domain at a time, and verify both the generated bytes and the real signal path.

Bridge fidelity report

What “Preserved unchanged” means

EdidCraft maps standards-safe fields into editable controls. Blocks without a complete semantic editor—often HDMI vendor data or some extension timings—are carried forward as validated raw bytes.

Imported
Editable in the Encoder
Preserved
Retained losslessly, not editable
Review
Valid transfer with a warning or contextual risk
Not imported
Source bytes were unavailable; abnormal for a normal bridge request
08

Reference

Glossary & quick answers

The vocabulary that appears most often in decoders, datasheets, and standards.

EDID

Extended Display Identification Data: display capability data read by a source.

E-EDID

The enhanced framework that includes the base EDID plus extension blocks.

DDC

The communication channel commonly used to retrieve EDID over HDMI/DVI-style connections.

DTD

An explicit 18-byte timing descriptor containing the waveform parameters for one mode.

VIC

A CTA-defined numeric identifier for a standardized video format.

SVD

A compact CTA Video Data Block entry that advertises a VIC and native status where defined.

SAD

A three-byte CTA audio capability record.

VSDB

A CTA block whose interpretation is owned by the organization identified in its payload.

OUI

An IEEE organizational identifier used to identify the owner of vendor-defined data.

DMT

VESA’s catalog of defined display monitor timing modes.

CVT

VESA’s equation-based method for generating coordinated video timings.

RB

Reduced Blanking: CVT timing families intended to reduce blanking overhead for non-CRT displays.

EOTF

The mapping from an electrical signal value to displayed light output; signaled by HDR capability data.

YCbCr 4:2:0

A chroma-subsampled encoding with lower chroma data rate than 4:4:4.

Frequently asked questions

Can an EDID force a source to output one mode?

It can strongly influence selection by advertising and prioritizing modes, but source policy, operating system settings, driver behavior, and link constraints still decide the actual output.

Why is my EDID 256 bytes instead of 128?

It contains the 128-byte base block plus one 128-byte extension. CTA-861 is the most common extension in HDMI-oriented systems.

Should I delete blocks my editor does not understand?

Usually no. Vendor and unimplemented blocks may carry essential link capabilities. Preserve them unless you understand their governing specification and intend to replace them.

Why do 59.94 Hz and 60 Hz both appear?

They belong to different frame-rate families and may use different exact clocks. A rounded UI label is not enough to prove two timings are identical.

Does recalculating the checksum repair a broken EDID?

It repairs only the checksum byte. Invalid lengths, reserved values, contradictory capability claims, and incorrect timings remain incorrect.

Local reference set

Standards used for this guide

Reviewed 9 August 2026
CTA

ANSI/CTA-861-H

CTA extension layout, video formats, data blocks, audio, colorimetry, HDR, and YCbCr 4:2:0 signaling.

VESA

E-EDID Verification Guide, Release A

EDID 1.4 base-block field layout, descriptor rules, checksums, and verification test cases.

VESA

DisplayID 2.1a + errata

DisplayID sections, data-block headers, timing blocks, interfaces, tiled displays, and modern capability structures.

VESA

CVT 2.1

Equation-based standard and Reduced Blanking timing generation methods.

VESA

DMT 1.0, Revision 13

The bundled catalog of VESA and industry display monitor timing definitions.

This educational summary is not a conformance specification. If it conflicts with a normative standard, the normative standard controls.

Put the model to work

Decode a real EDID while the byte map is fresh

Start with an original file, inspect its structure, then validate it before making changes.

Open DecoderOpen Validator