A storage device on its own is an undifferentiated run of sectors. The partition table is the small structure at the start that says where each region begins, how long it is, and roughly what it holds. Everything else — file systems, boot loaders, operating systems — sits on top of that description.
MBR: the original scheme
The Master Boot Record occupies the first sector of the drive. Within that single sector it packs a short run of boot code and a table with room for four entries. Each entry records a starting position, a length and a type byte.
Two consequences follow from the size of that structure. The first is the four-partition ceiling, worked around historically by making one entry an "extended" container holding further logical partitions inside it. The second is the addressing limit: the fields that record position and length are 32 bits wide, which stops the scheme describing anything beyond roughly 2 TB with conventional sector sizes.
There is a third, quieter consequence. The table exists in exactly one place. If that sector is damaged, nothing on the drive is described any more, even though every byte of your data is still physically present.
GPT: the modern scheme
The GUID Partition Table replaces the packed single sector with a proper on-disk structure. A header identifies the layout, an array of entries describes the partitions — typically 128 of them, each with a GUID identifying its type and another identifying that specific partition — and the whole thing is protected by checksums.
Crucially, a second copy of the header and entry array lives at the end of the drive. If the primary copy is damaged, tools can recover from the backup. Addressing fields are 64 bits wide, which removes the capacity ceiling from any practical conversation.
GPT also keeps a decoy MBR in sector zero, describing the whole drive as one partition of an unfamiliar type. Its only job is to stop older tools from concluding the drive is blank and helpfully offering to initialise it.
Side by side
| MBR | GPT | |
|---|---|---|
| Partition entries | 4, extended containers for more | 128 by default |
| Practical capacity | About 2 TB | Beyond any current drive |
| Table copies | One | Primary and backup |
| Integrity checking | None | CRC on header and entries |
| Partition identity | One type byte | Type GUID plus unique GUID |
| Typical firmware pairing | Legacy handoff | UEFI |
How this touches bootable media
The pairing in the last row is a convention rather than a law, but firmware behaviour follows it closely enough that it may as well be one. UEFI firmware expects to find an EFI System Partition, and it is looking for a GPT layout in the ordinary case. Legacy firmware wants boot code in sector zero, which is where MBR keeps it.
A drive prepared for one route and offered to firmware following the other will often simply not appear in the boot menu. Nothing is broken; the firmware looked in the place it knows about and found nothing it recognised.
Multiboot loaders generally handle this by preparing the drive so both entry points exist, so that whichever firmware reads it finds a route it understands. That is a convenience, not magic — the image files inside still need to support the mode that ends up being used.
Reading the layout before you change it
Whichever platform you are on, look before you write. Windows Disk Management shows partition style in a disk's properties. On Linux, lsblk gives you a quick tree of devices and sudo parted -l reports the table type for each. On macOS, diskutil list does the same job. Read the output twice, identify your target by size and by label, and only then act.
Converting between the two
Conversion tools exist on every platform and some can work without erasing data, but the operation rewrites the structure that describes where everything lives. Treat it as a task you only start after a verified backup, and expect to adjust firmware settings afterwards, since converting the system disk changes how the machine expects to boot.
For a drive you carry around, the calculation is simpler. If it is under 2 TB and needs to work on the widest possible range of machines, either scheme can be made to work. If it is larger, or if you want the redundancy of a mirrored table, GPT is the reasonable default.