Seven segments, one letter each
A seven-segment display forms each digit from seven individually controllable LED (or LCD) bars, conventionally labeled a through g in a standard layout used across virtually every datasheet and tutorial on the subject: a is the top bar, b and c are the upper-right and lower-right verticals, d is the bottom bar, e and f are the lower-left and upper-left verticals, and g is the middle horizontal bar. Any of the ten decimal digits (and the six hex letters A–F, on displays that support them) can be drawn by lighting the correct subset of these seven segments — an 8 lights all seven, a 1 lights only the two right-hand verticals (b and c), and so on.
Packing seven on/off states into one byte
Because there are exactly seven segments, their combined on/off state fits naturally into a single byte with one bit to spare, which is exactly how seven-segment driver hardware and firmware typically represent a digit: bit 0 for segment a, bit 1 for b, and so on through bit 6 for segment g, following the convention this tool uses (a=0x01, b=0x02, c=0x04, d=0x08, e=0x10, f=0x20, g=0x40). A microcontroller driving a seven-segment display typically writes exactly one such byte to a port or shift register per digit to control which segments light up, which is why representing a digit as a single hex byte is the natural, hardware-aligned format rather than an arbitrary encoding choice.
Why this bit convention specifically, and why it varies
There's no single universal standard for which bit corresponds to which segment — it depends on how a specific display driver chip or circuit wires its segments to its data lines, and different hardware designs assign the bits differently. This tool uses the common a=bit0 through g=bit6 convention, which matches a large fraction of datasheets and hobbyist tutorials, but a specific piece of hardware may wire its segments in a different bit order entirely. Anyone driving actual seven-segment hardware directly should confirm the bit assignment against that specific device's datasheet rather than assuming this tool's convention matches automatically.
A worked example
The digit 8 lights every segment, so its byte is all seven bits set: 0x01 + 0x02 + 0x04 + 0x08 + 0x10 + 0x20 + 0x40 = 0x7F. The digit 1 lights only segments b and c (the two right-hand verticals): 0x02 + 0x04 = 0x06. The digit 4 lights segments b, c, f, and g (both right-hand verticals, the upper-left vertical, and the middle bar, but neither the top nor bottom bar): 0x02 + 0x04 + 0x20 + 0x40 = 0x66. Multi-digit hex values convert one digit at a time, each producing its own independent byte, which is why this tool's output for a multi-digit hex string is a space-separated list of bytes rather than one combined value.
Reversing the process: bytes back to digits
Going from segment bytes back to hex digits requires matching each byte against the full table of valid digit patterns, since a byte that doesn't exactly match any known pattern doesn't correspond to a standard digit at all — it might represent a custom character some displays support (like a decimal point using an eighth bit, a dash, or letters beyond A–F on certain alphanumeric seven-segment modules), none of which this tool's basic 0–F digit table covers. This tool reports an error for any byte that doesn't exactly match one of the sixteen defined digit patterns, rather than guessing at the closest match, since an approximate match would likely represent a real hardware fault or a differently-wired display rather than the intended digit.
Where this shows up in practice
Beyond physical LED displays, this same digit-to-segment mapping appears in embedded firmware that drives seven-segment displays directly from a microcontroller's GPIO pins or a dedicated driver chip (like the common 74-series or MAX7219 display drivers), in simulation and schematic software that models seven-segment hardware, and occasionally in retro-computing and hardware-hacking contexts where an old device's stored digit data needs to be decoded back into readable numbers from raw dumped bytes.