How Internet Packets Break Apart and Reassemble Data

Why data is split into packets

Imagine sending a large photo to a friend as a single, uninterrupted transmission. If any part of that transmission were disrupted, you'd likely have to start over completely. Worse, while it was in progress, it would monopolize the shared network link, leaving no room for anyone else's traffic. The internet solves both problems the same way: it breaks data into small chunks called packets, each carrying a portion of the original file along with addressing information, and sends them independently.

This approach — packet switching — means many users and applications can share the same network links at once, interleaving their packets rather than waiting in line for a dedicated circuit. It also means that if a single packet is lost or damaged, only that small piece needs to be resent, not the entire file.

This is also why a poor connection tends to slow a download gradually rather than fail it outright. As packets are lost and resent, the transfer keeps making progress — just more slowly — instead of the whole thing collapsing the moment any single piece runs into trouble, the way an all-or-nothing transmission would.

What's inside a packet

Every packet has two basic parts: a header and a payload. The payload is the actual slice of data being carried — a fragment of a photo, a piece of a video stream, part of a web page. The header is much smaller, but it's what makes routing possible: it includes the source and destination addresses, along with details like the packet's size and its position in the sequence, so the receiving device knows how to fit each piece back together. Networks also define a maximum packet size, called the MTU (maximum transmission unit); data larger than that limit is split into multiple packets automatically.

A useful, if imperfect, analogy is a labelled envelope: the header is like the addressing on the outside, and the payload is like the letter inside. The comparison has real limits, though — unlike a physical envelope, a router doesn't open a packet to read a full address book entry. It matches the destination against a routing table in a fraction of a millisecond, and it does this for enormous numbers of packets continuously, not one at a time.

Packet switching and shared links

Because packets from many different connections travel over the same physical links, routers along the way have to handle a constant, mixed stream of traffic from countless unrelated sources. Each router looks at a packet's destination address, checks it against a routing table, and forwards it toward the next hop — a process covered in full in how routers find a path across the internet. When a link gets busy, packets queue briefly rather than being sent instantly, which is part of where latency under load comes from.

This sharing is what makes the internet efficient rather than wasteful: a link that carried only one connection's traffic at a time, waiting idle whenever that connection had nothing to send, would be a poor use of expensive infrastructure. Interleaving packets from many sources keeps busy links genuinely busy, at the cost of the small, variable queueing delay that shows up whenever demand briefly exceeds a link's capacity.

Ordering, loss, and reassembly

Because packets can travel independently, they don't always arrive in the order they were sent, and occasionally one doesn't arrive at all — dropped due to congestion, a damaged link, or an overloaded router along the way. Protocols that guarantee reliable delivery track which packets have arrived, request retransmission of anything missing, and reorder pieces that arrived out of sequence before handing the complete, correctly ordered data up to the application. Duplicate packets, which can occur when a retransmission and the original both eventually arrive, are simply discarded once recognized.

How disruptive loss feels depends heavily on what's being sent. Losing one packet out of a large file transfer is barely noticeable once it's resent — the file still arrives complete, just microscopically later. Losing packets in a live video call is different: there's often no time to wait for a retransmission before that data would be needed on screen, so the application typically just accepts the small gap, which is one reason a bad connection makes calls glitchy rather than simply slow.

IP, TCP, UDP, and QUIC: different jobs

The Internet Protocol (IP) handles addressing and forwarding — getting each packet from a source to a destination across many networks. On top of that, transport protocols decide how carefully to handle reliability and order. TCP guarantees delivery and order, at the cost of a brief setup delay and some overhead — a good fit for web pages, email, and file transfers, where a complete, correct copy matters more than saving a few milliseconds. UDP skips that overhead entirely, sending packets immediately without guarantees, which suits live video, voice calls, and gaming, where a slightly stale or missing packet is better handled by simply moving on than by waiting for a retransmission. QUIC, built on top of UDP, aims for the best of both: reliable, ordered delivery (per stream) with much faster connection setup, and it increasingly powers modern web traffic over HTTP/3.

It's worth resisting the instinct to rank these as simply "better" or "worse" than each other. Each one is a deliberate trade-off suited to a particular kind of traffic: choosing UDP for a video call isn't a shortcut or a compromise, it's the right tool for data where a slightly stale frame is far less disruptive than the delay of waiting for a perfect one.

Do packets really take different paths?

They can, but in practice most packets belonging to a single connection tend to follow a stable route for as long as network conditions don't change, since routers typically make consistent forwarding decisions for a given destination. Different paths become more likely when there are multiple valid routes and the network load-balances across them, or when a failure or congestion forces a mid-connection reroute. It's not that every packet is individually gambling on a random path — routing decisions are consistent and rule-based, just made independently by each network along the way.

What actually varies more often than the path is the timing: even packets sent along the exact same route can experience slightly different queueing delay at each router along the way if network conditions shift mid-stream, which is enough on its own to make packets arrive out of order without ever taking different physical paths.

What this means for your connection

Packet loss and out-of-order delivery are why a connection can feel choppy even when your average speed looks fine: retransmissions and reordering take time, and on latency-sensitive traffic like calls or games, that shows up as stutter or lag rather than a lower number on a speed test. A loaded-latency measurement, which checks responsiveness while your connection is under load, often reveals this kind of issue better than a plain download or upload number alone.

The next articles in this series build directly on this idea: how routers actually decide where each packet goes, and why the delay between sending a packet and it arriving is never quite zero, no matter how well the network is behaving.