Automation Glossary • CAN Identifier

What Is a CAN Identifier?

Merobix Engineering • • 5 min read

Every CAN message is labelled by an identifier, and that identifier does double duty: it names the content of the frame and it sets the frame's priority on the bus. Engineers new to CAN often expect an address that says which node to send to, and are surprised to find the identifier describes the message, not the destination. This page explains the 11-bit standard identifier and the 29-bit extended identifier, why CAN is content-addressed rather than node-addressed, and how to read an identifier off a bus analyzer.

Back to Blog

CAN Identifier in one line: A CAN identifier is the field at the start of every CAN frame that labels the message and sets its bus priority. A standard (base) frame uses an 11-bit identifier and an extended frame uses a 29-bit identifier. The identifier describes the message content, not a destination node, so CAN is content-addressed: every node hears every frame and filters by identifier to keep the ones it cares about.

11-Bit Standard and 29-Bit Extended Frames

Classic CAN defines two frame formats that differ only in identifier length. The base frame, from the original CAN 2.0A specification, carries an 11-bit identifier, giving 2048 possible values before reserved ranges. The extended frame, from CAN 2.0B, carries a 29-bit identifier, giving over half a billion values. A single bit in the frame, the identifier extension bit, tells receivers which format is on the wire, and both formats can coexist on the same bus.

The reason two formats exist is history plus scale. Eleven bits were plenty for a car's original body electronics, but higher-layer protocols that need to pack routing information into the identifier itself outgrew that space. J1939, for instance, uses the full 29-bit extended identifier to encode a priority, a parameter group number, and a source address all inside the arbitration field, which is impossible in 11 bits. CANopen, by contrast, lives comfortably inside the 11-bit standard identifier because it addresses a modest number of nodes.

The Identifier Names the Message, Not the Node

The most important conceptual point about a CAN identifier is that it is not a destination address. When a node transmits, it does not aim the frame at another node; it broadcasts a message labelled with an identifier that means something agreed by the whole network, such as engine speed or coolant temperature. Every node on the bus receives every frame and its controller applies acceptance filters to decide which identifiers to pass up to software and which to ignore in hardware. This is content addressing, and it is why one sensor's reading can feed many consumers with a single frame.

Because the identifier also governs arbitration on the CAN bus, its numeric value is never arbitrary. A lower identifier is a higher-priority message, so identifier assignment is simultaneously a naming decision and a priority decision. Two producers must never share an identifier, or their frames would collide during arbitration and corrupt each other, which is why higher-layer protocols hand out identifier ranges systematically rather than letting integrators pick numbers freely.

This model is the opposite of a polled fieldbus like Modbus, where a unit ID names the target device and a master asks it for data. On CAN there is no master doing the asking; producers publish and consumers filter. Recognizing that difference is what stops people from hunting for a nonexistent destination field when they first read a CAN trace.

Reading an Identifier Off the Bus

On a bus analyzer or logging tool, identifiers are usually shown in hexadecimal, and the display will tell you whether each frame is standard or extended. An 11-bit identifier fits in three hex digits (0x000 to 0x7FF), while a 29-bit identifier needs up to eight (0x00000000 to 0x1FFFFFFF). If you see eight-digit identifiers, you are almost certainly looking at an extended-frame protocol such as J1939 or NMEA 2000, and the raw number can be decoded further into its embedded fields.

A frequent point of confusion is that the same physical parameter can appear under different identifiers on different vehicles or machines, because the mapping from identifier to meaning is defined by the higher-layer protocol or the manufacturer, not by CAN itself. Classic CAN is only the transport; the meaning of identifier 0x0CF00400 comes from the J1939 database, and the meaning of a CANopen frame comes from the node's device profile and its object dictionary. Without that layer, an identifier is just a priority tag on an anonymous block of bytes.

When you bring CAN data into a gateway for monitoring, the identifier is the key you map against. You tell the gateway which identifiers to capture and how to interpret their payload, then it publishes named tags upward. Getting the identifier and frame format right is the first thing to verify, because a gateway configured for 11-bit frames will silently ignore a device that only speaks in 29-bit extended frames.

Frequently Asked Questions

What is the difference between an 11-bit and a 29-bit CAN identifier?

An 11-bit identifier belongs to a standard (base) CAN frame and allows 2048 values, while a 29-bit identifier belongs to an extended CAN frame and allows over 500 million values. Both formats can share the same bus, and a bit in the frame flags which is in use. Protocols like J1939 need the 29-bit identifier to pack a priority, parameter group number, and source address into the arbitration field, whereas CANopen fits within the 11-bit identifier.

Is a CAN identifier a device address?

No. A CAN identifier labels the message and its meaning, not a destination node. CAN is content-addressed: a transmitter broadcasts a frame with an identifier, every node receives it, and each node filters in hardware for the identifiers it wants. There is no master asking a specific device for data the way a Modbus master polls a slave address, so a CAN identifier says what the message is, not who it is for.

How do I read a CAN identifier on a bus analyzer?

Analyzers usually show identifiers in hexadecimal and mark each frame as standard or extended. An 11-bit identifier fits in three hex digits (up to 0x7FF); a 29-bit identifier needs up to eight (up to 0x1FFFFFFF). Eight-digit identifiers indicate an extended-frame protocol such as J1939 or NMEA 2000, whose embedded fields can be decoded further using that protocol's database.

Sources and verification

This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.

Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.

More in General Automation Concepts
MQTT Subscription Identifier  •  BACnet Object Identifier  •  Modbus Transaction Identifier  •  CAN Bit Stuffing  •  CAN FD  •  All General Automation Concepts →
Free SCADA operator training
Merobix University - 70 video lessons & 261 quiz questions, from first login to compliance reporting. No demo call required.
Start free →