Free FIX Message Parser
Paste FIX messages from a log to see every tag named, values explained, and BodyLength and CheckSum checked.
What is a FIX Message Parser?
FIX, the Financial Information eXchange protocol, is how brokers, exchanges and trading firms send orders and fills. Each message is a string of tag=value pairs, such as 35=D for a new order, separated by an invisible SOH character. This parser turns them into readable fields.
It reads FIX 4.0 to 4.4 and FIX 5.0 over FIXT 1.1, with SOH, pipe, ^A or <SOH> delimiters, and several messages per paste. Every tag in its dictionary is named, order types, sides, statuses and reject reasons are explained, and BodyLength and CheckSum are recomputed.
Key Features
Tags Named
About eighty common tags, from ClOrdID and OrdType to MDEntryType and SessionRejectReason.
Values Explained
Message types, sides, order types, time in force, statuses, execution types and reject reasons in words.
Checks Recomputed
BodyLength and CheckSum recalculated with real SOH bytes, whatever delimiter your log shows.
Whole Logs
Several messages per paste, with log timestamps and directions before 8=FIX skipped.
Passwords Masked
Tag 554 is hidden in the output, and nothing is uploaded.
Perfect for everyone
- Trading system developers
- FIX onboarding and support engineers
- QA testers and anyone reading a FIX log
How to Use the FIX Message Parser
Copy messages from a log and paste them.
Copy From the Log
QuickFIX, an OMS or a broker’s portal prints messages with | or ^A in place of SOH.
Paste Them
One message or a whole session. Text before each 8=FIX is ignored.
Read the Fields
Each message shows its type, sender, target and sequence, then every field.
Check the Results
BodyLength and CheckSum mismatches are flagged at the top of each message.
FIX Messages, Parsed
Each row is a FIX message as a log prints it, and each answer is this parser’s output in the mode on the chip. All the checksums were computed with real SOH bytes.
“8=FIX.4.4|9=74|35=A|49=BUYSIDE|56=BROKER|34=1|52=20261027-14:30:00.000|98=0|108=30|141=Y|10=244|”
“8=FIX.4.4|9=147|35=D|49=BUYSIDE|56=BROKER|34=2|52=20261027-14:30:01.250|11=ORD-1001|1=ACC-77|21=1|55=MSFT|54=1|60=20261027-14:30:01.249|38=500|40=2|44=412.50|59=0|10=073|”
“8=FIX.4.4|9=190|35=8|49=BROKER|56=BUYSIDE|34=7|52=20261027-14:30:02.004|37=BRK-88123|11=ORD-1001|17=EXE-5541|150=F|39=1|55=MSFT|54=1|38=500|32=200|31=412.48|151=300|14=200|6=412.48|60=20261027-14:30:02.003|10=141|”
“8=FIX.4.2^A9=65^A35=A^A49=SERVER^A56=CLIENT^A34=177^A52=20090107-18:15:16^A98=0^A108=30^A10=062^A”
“8=FIX.4.2|9=56|35=0|49=BUYSIDE|56=BROKER|34=3|52=20261027-14:30:30.000|10=161|”
“8=FIX.4.4|9=106|35=3|49=BROKER|56=BUYSIDE|34=8|52=20261027-14:30:03.000|45=3|371=44|372=D|373=5|58=Price must be positive|10=032|”
“14:31:10.004 OUT 8=FIX.4.4|9=118|35=F|49=BUYSIDE|56=BROKER|34=4|52=20261027-14:31:10.000|41=ORD-1001|11=ORD-1002|55=MSFT|54=1|60=20261027-14:31:10.000|10=078|”
“8=FIX.4.4|9=90|35=A|49=BUYSIDE|56=BROKER|34=1|52=20261027-14:29:59.000|98=0|108=30|553=desk7|554=hunter2|10=056|”
“8=FIX.4.4|35=0|9=5|10=000|”
“35=D;55=MSFT;54=1”
The Fields Every Message Has
A FIX message has a standard header, a body and a trailer. These ten fields appear in almost every message.
8 BeginString
The protocol version, always first: FIX.4.2, FIX.4.4 or FIXT.1.1.
“Which version does FIX 5.0 use here?”
9 BodyLength
Bytes from after this field up to the SOH before 10=, always second.
“Does it include the CheckSum field?”
35 MsgType
What the message is, always third: A logon, D new order, 8 execution report.
“What is 35=8?”
49 SenderCompID
The firm or system sending the message.
“Which side is 49 in a reply?”
56 TargetCompID
The firm or system it’s addressed to.
“What is 56 in a logon to a broker?”
34 MsgSeqNum
A sequence number per direction, used to detect gaps and resend.
“What happens after a gap?”
52 SendingTime
When it was sent, in UTC as yyyyMMdd-HH:mm:ss.sss.
“Which timezone is it in?”
11 ClOrdID
The client’s own ID for an order, unique per day per session.
“Who chooses ClOrdID?”
10 CheckSum
The sum of every byte before it, modulo 256, as three digits.
“How many digits?”
58 Text
Free text, often the reason for a reject.
“Is Text machine-readable?”
How an Order Flows
A single order produces a short conversation between client and broker. These are the messages you will see in a typical session log, in roughly the order they appear.
Logon (A)
Both sides exchange logons with a heartbeat interval before any business messages.
New Order Single (D)
The client sends symbol, side, quantity, order type and price with its ClOrdID.
Execution Report (8), New
The broker acknowledges with ExecType 0 and an OrderID of its own.
Execution Report (8), Trade
Each fill reports LastQty and LastPx, with CumQty and LeavesQty updated.
Cancel or Replace (F, G)
The client asks to cancel or amend, referring to the order by OrigClOrdID.
Heartbeats (0)
When nothing else is sent, heartbeats keep the session alive at the agreed interval.
Session-Level Problems
Most FIX support tickets are about the session layer rather than orders. These are the messages and fields to look at when a connection misbehaves.
Session Reject (3)
A message broke the protocol. RefTagID and SessionRejectReason say which field and why.
Business Reject (j)
The message was valid FIX but the application refused it.
Resend Request (2)
A sequence gap was found. The other side replays or gap-fills the missing range.
Sequence Reset (4)
GapFillFlag Y skips messages that don’t need resending; without it, it resets the sequence.
Wrong CheckSum
Messages with a bad checksum are dropped silently by most engines, so check it first.
Logout (5)
Read its Text field: it usually says why the counterparty ended the session.
When to Parse FIX
Whenever a FIX log needs reading quickly.
Order Investigations
Follow an order from new to filled to see what happened and when.
Counterparty Onboarding
Check that test messages match a broker’s rules of engagement.
Debugging Rejects
Find the field and reason behind a session or business reject.
Building an Engine
Compare your BodyLength and CheckSum with the values recomputed here.
Learning FIX
See what each tag means in real messages.
FIX Pitfalls
Mistakes that break FIX messages.
Pipes Aren’t SOH
Logs show | for readability. A checksum computed over pipes is wrong; compute it over SOH.
Header Order
8, 9 and 35 must be the first three fields and 10 the last.
Counting BodyLength
It starts after 9=…SOH and ends with the SOH before 10=, counting bytes, not characters.
Version Differences
ExecType 1 and 2 exist in FIX 4.2 but were replaced by F (trade) in 4.4.
Custom Tags
Tags 5000 to 9999 are user-defined, so their meaning comes from the counterparty.
Repeating Groups
Fields in a group must follow their NoXXX count tag in order, or the message is rejected.