Free EDI File Viewer

What is X12 EDI?

EDI (Electronic Data Interchange) is how businesses have exchanged structured documents — purchase orders, invoices, shipment notices — since long before web APIs existed. In North America the dominant dialect is ANSI ASC X12: a plain-text format where every field is separated by a fixed delimiter and every document type has a 3-digit transaction set number. It looks like gibberish at a glance — BEG*00*SA*PO-100234**20260710~ — but every character has a defined meaning once you know the segment dictionary. This EDI file viewer decodes that dictionary for you so you can read a raw file the same way an EDI translator would, without owning one.

The envelope: ISA, GS, ST

Every X12 file nests inside three envelope layers, each opened by a header and closed by a matching trailer:

• ISA / IEA — Interchange: The outermost envelope: one trading-partner-to-trading-partner transmission, with sender/receiver IDs, a date/time, and the delimiters used for the rest of the file.
• GS / GE — Functional group: Batches transaction sets of the same type (e.g. all the 850s in this transmission) from one sender to one receiver, with its own control number.
• ST / SE — Transaction set: One actual document — one purchase order, one invoice, one ASN — identified by a 3-digit code (850, 810, 856...) and a control number that must match between ST02 and SE02.

A single .edi file can technically hold multiple interchanges, functional groups, and transaction sets — but the common case, especially when a file lands in an email, is one interchange with one transaction set inside. This viewer handles both: it renders every layer it finds and flags any control-number mismatch between a header and its trailer as a warning instead of refusing to show you the file.

The big three transaction types

Hundreds of X12 transaction sets exist, but three cover most retail and supply-chain EDI: the purchase order, the invoice, and the advance ship notice. This viewer gives all three dedicated structured parsing — line items, parties, and totals extracted, not just labeled segments.

• 850 — Purchase Order: What a buyer sends to order goods: a PO number and date (BEG), ship-to/bill-to addresses (N1 loops), and one PO1 line per item ordered with quantity, unit price, and product IDs.
• 810 — Invoice: What a supplier sends to bill for goods already shipped: an invoice number tied back to the PO (BIG), IT1 line items, and a TDS total — often cross-referenced against the 850 and 856 for three-way matching.
• 856 — Advance Ship Notice (ASN): Sent before a shipment physically arrives, describing exactly what's inside via a nested HL hierarchy: shipment → order → pack → item, each with its own packaging, routing, or quantity detail.

Want the full walkthrough of one document type? Read What Is an EDI 850? or EDI 856 Errors That Trigger Retailer Chargebacks in the Learn section. Other transaction types (997 functional acknowledgments, 855 PO acknowledgments, and more) still render with plain-English segment names — they just don't get the extra structured/JSON extraction the big three do.

Common EDI errors this viewer catches

EDI files rarely fail loudly — a trading partner's translator either silently rejects the interchange or, worse, accepts it and the mismatch surfaces days later as a chargeback. The most common issues:

• Control number mismatches: SE01 doesn't match the actual segment count, or SE02/GE02/IEA02 doesn't match its header's control number. Many trading partners' translators reject the whole interchange on this alone.
• Wrong or inconsistent delimiters: The element, sub-element, and segment separators are declared once in the ISA header (usually * : and ~) and must be used consistently for the entire file — a stray delimiter character inside free-text data will desynchronize the parser.
• Missing or malformed HL hierarchy in an 856: Each HL segment declares its own ID and its parent's ID. A broken parent reference, a level code that doesn't match the actual nesting, or a shipment with no item-level HL nodes at all is one of the most common causes of retailer ASN chargebacks.
• Quantity or PO mismatches across documents: The 850's ordered quantity, the 856's shipped quantity, and the 810's invoiced quantity should reconcile. A mismatch is usually legitimate (backorders, substitutions) but needs to be visible, not buried in raw segments.

How to use this EDI viewer

1. Paste the file's contents (straight out of an email or FTP client) or drop the .edi/.x12/.txt file above. Nothing is uploaded — parsing happens entirely on your device.
2. Check the transaction summary: type, PO/document number, partner IDs, counts, and any control-number warnings.
3. Browse the segment view — every segment expandable, every element labeled — or switch to JSON view for the structured, developer-ready version.
4. Export the flattened line items as CSV, XLSX, or JSON.

FAQ