Should I enable Includes FCS for every capture?

No. Many capture paths omit FCS. Enable the option only when the final four bytes contain the frame checksum.

Why does Data contain padding in an EtherType frame?

EtherType identifies a protocol without specifying its payload length. The parser cannot separate padding without decoding that inner protocol.

Does a valid FCS prove the payload is valid?

No. FCS checks frame integrity. It does not validate inner protocol fields or establish the sender's identity.

Ethernet frame Parser | Tool Factory

Tool workspace

Packet bytes stay in this browser. Checksum checks use only the addresses you enter.

Needs input

Run the tool when your input is ready.

Packet bytes

Start with the destination MAC address. Exclude the preamble and start delimiter. Select Includes FCS only when present.

Options

Input format

Includes FCS

Check the final four bytes as Ethernet CRC-32. Captures often omit these bytes.

Your result appears here

Parse Ethernet MAC addresses, VLAN tags, EtherType, and IEEE 802.3 lengths. Separate padding and check a supplied CRC-32 FCS.

This tool runs open-source code from CyberChef by GCHQ (Apache License 2.0). See open-source credits.

Ethernet frame Parser reads destination and source MAC addresses, VLAN tags, and the type or length field. Values through 1500 specify IEEE 802.3 data length. Values from 1536 specify EtherType. Enable Includes FCS only when the capture retains its four-byte frame check sequence. The parser then checks Ethernet CRC-32.

The JSON reports MAC addresses, VLAN fields, Data, Padding, and FCS check. The byte table shows each field's position.

Locate the inner type field after stacked 0x8100 or 0x88a8 VLAN tags.
Distinguish IEEE 802.3 payload length from EtherType.
Check a retained frame checksum against all preceding frame bytes.

Sources: IEEE 802.3 working group: Ethernet frame layout; IEEE 802.1Q: VLAN bridges

Instructions

Copy frame bytes starting at the destination MAC address. Omit the preamble and start frame delimiter.
Choose Hex for captured bytes. Select Includes FCS only when the capture documentation confirms those final four bytes.
Select Parse bytes. Compare VLAN TPID, PCP, DEI, and VID with the capture's decoded fields.
Read Data separately from Padding when the frame uses an IEEE 802.3 length field.
Select Run working sample to inspect four data bytes, 42 padding bytes, and a checked Ethernet FCS.

Example

Input: ff ff ff ff ff ff 02 00 00 00 00 01 00 04 aa aa 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 63 34 37

Settings: Input format: Hex; Includes FCS: true.

Result: { "Destination MAC": "ff:ff:ff:ff:ff:ff", "Source MAC": "02:00:00:00:00:01", "VLANs": [], "IEEE 802.3 length": 4, "Header bytes": 14, "Data": "aaaa0300", "Padding": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000", "FCS check": { "status": "Valid", "received": "f3633437", "expected": "f3633437" }, "Size note": "Capture includes at least 60 bytes without FCS." }

The sample follows the IEEE 802.3 length layout. Its four opaque data bytes demonstrate padding separation, not an inner protocol exchange.

Limits

The parser rejects incomplete headers, truncated VLAN tags, reserved VLAN ID 4095, and undefined type/length values 1501 through 1535.
A short capture can omit padding. The result reports fewer than 60 bytes without FCS without claiming wire-level validity.
EtherType frames do not carry a payload length here. Their Data field includes any captured padding.
The parser checks supplied FCS bytes in wire order. It cannot verify a checksum that the capture omitted.
The input limit is 65535 bytes. MAC parsing does not validate inner LLC, ARP, IPv4, IPv6, or application data.