Packet dissect // cross-layer

Paste a captured frame and watch the encapsulation unfold: Ethernet II, VLAN tags, IPv4 or IPv6, TCP, UDP or ICMP, then DNS, DHCP, HTTP, TLS or an unknown payload. Every layer links back to its dedicated explorer, and every byte range maps to a highlighted hex view.

cross-layer · Ethernet to application offset-linked hex per-layer warnings Ethernet IPv4 IPv6 UDP DNS DHCP HTTP TLS

input hex frame or packet walk link → network → transport → app output layer tree + hex + fields limits no decryption or reassembly

walk
tree
method
limits

01Packet walk

paste bytes · choose a starting layer · read the chain

dissect bytes

waiting

hex input Ethernet frame, IPv4 packet, IPv6 packet or raw bytes

starting layer

No frame dissected yet.

layer tree

02How the walk works

each layer names the next one

A dissector does not guess the whole stack at once. Each header carries the identifier needed to find the next header. Ethernet has an EtherType, IPv4 has a Protocol byte, IPv6 has a Next Header chain, and TCP/UDP have ports that suggest an application protocol. The walk stops when a layer has no decoder, when a length check fails, or when a fragment does not contain the transport header.

Layer	Selector	Values followed here	Next
Ethernet II	EtherType at offset 12	`0x0800` IPv4 · `0x0806` ARP · `0x86DD` IPv6	IPv4 / IPv6 / ARP
802.1Q / 802.1ad	TPID `0x8100` / `0x88A8`	One or more 4-byte tags	Inner EtherType
IPv4	Protocol byte at offset 9	`1` ICMP · `6` TCP · `17` UDP	Transport header
IPv6	Next Header byte at offset 6	Hop-by-Hop, Routing, Fragment, AH, Destination Options	Terminal transport header
TCP / UDP	Port numbers and payload shape	53 DNS · 67/68 DHCP · 80/8080 HTTP · 443 TLS/QUIC · 179 BGP	Application layer

ports are hints, not proof

A UDP datagram to port 53 is usually DNS and one to port 67/68 is usually DHCP, but nothing in UDP enforces that. The dissector tries the application decoder only when the payload parses; otherwise it shows an opaque payload layer. Unknown protocols are a normal result, not a failure.

03Limits & safety

what this tool deliberately does not do

No decryption. TLS application data (including HTTP inside HTTPS), QUIC protected packets, ESP and encrypted BGP sessions remain opaque.
No IP reassembly. A non-initial IPv4 or IPv6 fragment has no transport header. The dissector marks fragment data and stops instead of inventing a payload.
No TCP stream reassembly. One TCP segment is one input. A DNS message split across segments needs a stream reassembler, not a single-frame dissector.
No pcap import. The input is hex bytes. Extract one packet from your capture tool, or use the protocol pages for a specific header.
No checksum enforcement. Invalid checksums are reported as warnings. Offloaded NICs often emit frames before the checksum is filled in, so a capture can legitimately show a bad value.
Every parse is bounded. Pointer chains, extension-header chains and record counts all have guards, so malformed input produces warnings rather than an infinite loop.

captures can be hostile

Treat pasted bytes as untrusted input. This page never executes payloads, never dereferences pointers outside the buffer, and never makes a network request. It also does not prove that a frame was valid on the wire; it only shows what its bytes say.

Start with the dedicated explorer for the layer you care about, or open DNS, DHCP, HTTP, TLS, UDP, IPv6 or Ethernet to edit a header field by field.

next tool HTTP messages & framing ->