Paste EDI above or load an example to see the parsed structure.
🔒 Parsed entirely in your browser. No EDI or PHI is uploaded.
Paste an X12 interchange — a full ISA/GS envelope or a single ST/SE transaction — into the input box, or open a .edi/.txt/.835/.837 file with the file button.
The viewer detects the delimiters from the ISA header (or falls back to the conventional * : ~ set) and parses instantly as you type.
Read the summary for the interchange sender/receiver, control number, delimiters, and a count of transactions by type (e.g. 837×2).
Expand each transaction to see its segments, each broken into named, numbered elements with composite sub-elements split out (for example CLM05 shown as 11 : B : 1).
Load one of the built-in examples (837 claim, 835 remittance, 270 eligibility) to see the structure without pasting your own data.
Parse professional and institutional 837 claims and 835 remittance advice (ERA) with the same tool, plus eligibility transactions such as 270/271. Segments are grouped into their ST/SE transactions automatically.
Known segments (CLM, SVC, CLP, CAS, NM1, and dozens more) are labelled with human-readable names, and every element is numbered (NM101, NM102…) with composite sub-elements split on the component separator.
The element, component, and segment delimiters are read directly from the fixed-width ISA header, so files that use non-standard separators parse correctly without any configuration.
The parser flags structural problems — an SE with no matching ST, a transaction left open with no closing SE, or a second ST before the previous one closed — so you can spot envelope errors quickly.
Everything is parsed in your browser with no uploads. Because protected health information in a claim never leaves your machine, the viewer is safe to use for troubleshooting real payer files.
Claim and remittance files routinely contain protected health information — patient names, member IDs, diagnosis and procedure codes. This viewer parses everything locally in JavaScript, so none of that data is ever uploaded, logged, or stored. That makes it safe to inspect a real 837 or 835 during a billing investigation without a business-associate agreement or a data-exposure risk, and it keeps working on a locked-down or offline machine.
Rather than dumping a wall of pipe-delimited text, the viewer groups segments into their transactions, names the ones that matter for claims and payments, and splits composite elements so a value like a procedure code with modifiers is readable at a glance. That is exactly what you need when reconciling an 835 against the 837 that produced it, or tracing why a clearinghouse rejected a file.
The tool faithfully parses X12 structure and names known segments, and it flags envelope-level problems — but it does not pretend to be a full implementation-guide validator. You get a fast, accurate inspection of the actual bytes, which is what most day-to-day EDI troubleshooting requires, without false confidence about loop-level compliance.
There is no account, no per-file limit, and no upload wait. Paste a transaction and it parses immediately; load a built-in example to learn the structure. Because it is a static page, it opens instantly and can be bookmarked for the next time a file needs a quick look.
ANSI ASC X12 is the electronic data interchange standard behind most electronic healthcare administrative transactions in the United States. When a provider bills a payer, the claim travels as an 837; when the payer responds with payment and adjustment detail, it comes back as an 835 remittance advice, also called an ERA (electronic remittance advice). Being able to read these files quickly is a core skill for billing analysts and integration engineers, and it starts with understanding the envelope structure.
X12 data is wrapped in nested envelopes. The outermost is the interchange, opened by an ISA segment and closed by IEA. The ISA is unusual: it is a fixed-width, 106-character segment, and its layout is what tells a parser which delimiters the file uses. Inside the interchange are one or more functional groups, each opened by GS and closed by GE, which bundle transactions of the same type. Inside a group are the transaction sets themselves, each opened by ST and closed by SE. The ST01 element carries the transaction type — 837 for a claim, 835 for remittance — and ST02 carries a control number that the matching SE echoes.
Within a transaction, data is organized into segments (a segment identifier followed by data elements) terminated by a segment delimiter, conventionally a tilde. Elements within a segment are separated by an element delimiter, conventionally an asterisk, and composite elements are further divided into components by a component delimiter, conventionally a colon. So a segment like CLM*CLAIM001*150.00***11:B:1*Y*A*Y*Y~ has the identifier CLM, a claim ID in CLM01, a monetary amount in CLM02, and a composite in CLM05 whose components are 11, B, and 1. The actual delimiters are declared in the ISA, which is why a robust viewer reads them from the header rather than assuming.
An 837 describes who is billing, for which patient and subscriber, and for what services. Key segments include BHT (beginning of the hierarchical transaction), HL segments that build the billing-provider → subscriber → patient hierarchy, NM1 name segments identifying each party, CLM for the claim itself, HI for diagnosis codes, and service lines such as SV1 (professional) or SV2 (institutional). Reading a claim is largely a matter of following the HL hierarchy and matching each service line to its charges.
An 835 explains how a payer adjudicated the claims in a payment. The BPR segment carries the financial and payment-method detail, TRN the trace number used to reassociate the ERA with the actual deposit, CLP the claim-level payment (charged vs paid amount, patient responsibility, claim status), and SVC the service-line payment. Adjustments appear in CAS segments, which use Claim Adjustment Group Codes (such as PR for patient responsibility or CO for contractual obligation) together with Claim Adjustment Reason Codes (CARC) and Remittance Advice Remark Codes (RARC) to explain exactly why the paid amount differs from the charge. Reconciliation means matching each CLP back to the CLM in the originating 837 and confirming that charges, payments, and adjustments balance.
Most EDI problems are structural or reconciliation issues. A clearinghouse rejection often traces to a malformed envelope — a missing SE, a control-number mismatch between ST and SE, or an interchange whose segment count is wrong. Payment discrepancies usually come down to reading the CAS adjustments correctly: a claim that paid less than expected will have group and reason codes explaining the write-off or patient responsibility. Being able to open the raw file, see the segments named and the composites split, and spot an unclosed transaction at a glance turns a frustrating hunt through pipe-delimited text into a quick, methodical review.
A billing analyst chasing a partially paid claim line starts at the CLP segment, compares CLP02 (the charged amount) to CLP04 (the paid amount), then reads every CAS segment attached to it: the first component is the claim adjustment group code — PR for patient responsibility, CO for contractual obligation, OA for other adjustment — followed by a reason code and the adjusted amount. A synthetic line such as PR*1*45.00 next to a service means the plan assigned $45 of patient responsibility under reason code 1 (deductible), a read that takes seconds once the segments are split instead of counted by hand.
A second common task is tracing a clearinghouse rejection back to its cause. Pasting the raw 837 into the viewer surfaces a structural warning immediately — an ST with no matching SE, or an SE02 control number that fails to echo its ST02 — which usually explains the rejection before a single element needs inspecting. What would otherwise be a manual count against ISA13, GE02, and IEA01 becomes an instant diagnosis.
A third scenario is confirming an eligibility check. A synthetic 270 request and its paired 271 response can be pasted one after another; matching the BHT03 reference number between the two, then reading the EB segment's eligibility and benefit codes in the 271, confirms whether a patient's coverage was active on the date of service — useful groundwork when a claim later denies for an eligibility reason.
This viewer is a structural inspector, not a claims-adjudication engine or a certified TR3 implementation-guide validator. It will not tell you whether a procedure code, a diagnosis pointer, or a place-of-service value is valid for a given payer, and it does not calculate expected reimbursement or check loop-level requirements from a payer's companion guide. It also does not redact or strip the protected health information a claim contains — the file is parsed, not altered — so a raw 837 or 835 still needs the same care in storage and disposal after you close the tab. For certifying that an implementation guide's requirements are met, a dedicated TR3-aware validator is the right tool; this viewer's job is making the raw bytes readable in seconds, not certifying compliance.
The 837 and 835 are two of several HIPAA-mandated X12 transaction sets that move data between providers and payers. Knowing where a given transaction sits in that set helps when a file arrives unlabeled:
| Transaction | Direction | Purpose | Key segments |
|---|---|---|---|
| 837 | Provider → Payer | Health care claim (837P professional, 837I institutional) | CLM, HI, SV1/SV2 |
| 835 | Payer → Provider | Remittance advice (ERA) | CLP, CAS, SVC |
| 270/271 | Provider ↔ Payer | Eligibility inquiry / response | EQ, EB |
| 276/277 | Provider ↔ Payer | Claim status inquiry / response | STC |
Full transaction-set definitions and the version identifiers (such as 005010X222A1 for the 837P) are maintained by ASC X12 and referenced by CMS as the adopted HIPAA standards.
Every 837 carries a patient's name, member ID, and diagnosis or procedure codes; every 835 carries the same patient tied to a paid amount. Under HIPAA those fields are protected health information, and routing them through a third-party web service would typically require a business associate agreement. Because this viewer parses the file entirely in the browser's own JavaScript engine — no fetch call, no server round-trip, nothing reading the pasted text but your own machine — a billing analyst can open a real payer file on a locked-down workstation or an offline laptop and the PHI in it never leaves that device. That is the practical difference between a tool that is safe only with synthetic data and one built to handle actual production files.
An 837 diagnosis pointer in the HI segment references an ICD-10-CM code, which you can confirm directly in the ICD-10-CM Browser to check that the code description matches the billed service. If you need to share an excerpt of a claim or remittance with a colleague or a support ticket, paste the same text into the HIPAA PHI Identifier first — it scans plain-text files, EDI included, for exposed names, member IDs, and dates before anything leaves your hands. Together the three tools cover the common cycle of an EDI investigation: read the transaction, verify the codes it references, and confirm no protected health information remains in whatever you export or forward.
Any ANSI ASC X12 interchange, with a focus on healthcare transactions: 837 professional and institutional claims, 835 remittance advice (ERA), and eligibility transactions such as 270/271. You can paste a full ISA/GS envelope or just a single ST/SE transaction.
No. All parsing happens locally in your browser using JavaScript. The file you paste or open — including any protected health information it contains — is never uploaded, stored, or transmitted to any server.
It reads them from the fixed-width ISA header, where the element, component, and segment delimiters are defined. If there is no ISA (for example when you paste a single transaction fragment), it falls back to the conventional asterisk, colon, and tilde.
Not fully. It faithfully parses structure, names known segments, splits composite elements, and flags envelope problems like an unclosed transaction — but it does not perform complete TR3/implementation-guide loop and code-set validation. It is an inspection and troubleshooting aid, not a certified validator.
Yes. By breaking out the CLP and SVC payment segments and the CAS adjustments in the 835, and the CLM and service lines in the 837, the viewer makes it straightforward to match claims by control number and see how charges, payments, and adjustments relate.
A composite element packs several related values into one element, separated by the component delimiter. The viewer splits them so each component is visible. What each component means depends on the segment and position — for example a place-of-service composite or a procedure code with modifiers.
Yes. Once the page has loaded, no network connection is required. Because it is a static page with all parsing done client-side, you can use it on a locked-down or air-gapped machine where uploading a claim file would not be permitted.
No. This is an administrative and billing tool for reading EDI structure. It is not a clinical system and must never be used for diagnosis, treatment, or any patient-care decision.
No. It parses and names X12 structure — segments, elements, and composites — but it does not look up procedure or diagnosis codes against an official code set. Pair it with a dedicated code browser, such as an ICD-10-CM lookup, to confirm a code referenced in an HI or SV1 segment is valid and current.
Check the CAS segments attached to that service line. A $0 payment almost always comes with adjustment reason codes explaining the full write-off — for example a CO (contractual obligation) group code paired with a reason for a non-covered service, or a PR (patient responsibility) amount equal to the full charge. The viewer displays CAS segments right next to the CLP/SVC lines they adjust, so the reason is visible without cross-referencing a separate code list.
A practical guide to the X12 837 claim and 835 remittance (ERA): what each contains, how they reconcile, and how to read the segments that matter.
Read more →