What is actually inside a network packet?
Layers of headers wrapped around your data, each added by a different part of the networking stack and each read by a different piece of equipment along the way.
Why layers exist. Each layer solves one problem and does not need to understand the others. A router moving a packet across the internet does not care whether it contains an email or a video frame; a web browser does not care whether the packet travelled over Wi-Fi or fibre. This separation is what allows the internet to run over any physical medium and carry any application.
Working outward from your data:
Application data — the actual content: the HTTP request, the DNS query, the video frame.
Transport header (TCP or UDP) — source and destination port numbers, identifying which application on each machine. TCP adds sequence and acknowledgement numbers, flags and a window size.
Network header (IP) — source and destination IP addresses, plus a TTL (time to live) that decrements at each router, a protocol field, and fragmentation information. This is the header routers actually use.
Link header (Ethernet or Wi-Fi) — source and destination MAC addresses, identifying the immediate next device on the local link only. This header is rewritten at every hop, which is the key thing people miss: MAC addresses are local, IP addresses are end to end.
Frame check sequence at the end, detecting corruption.
What changes as it travels. The IP addresses stay the same end to end (unless NAT rewrites them). The MAC addresses change at every router. The TTL decreases by one each hop — and if it reaches zero, the packet is discarded and an error is returned, which is exactly how traceroute works.
What encryption hides. TLS encrypts the application data. It does not encrypt the IP and TCP headers — so anyone observing the path still sees who is talking to whom, how much, and when. That metadata is frequently more revealing than the content.
MTU limits packet size, typically 1500 bytes on Ethernet.