Free tool
HL7 Parser — free online HL7 v2 message viewer
Paste an HL7 v2 message to see every segment, field, repetition and component with its position (PID-3, OBX-5) and its HL7 v2.5.1 field name. The parser reads the delimiters from MSH, decodes escape sequences, summarises the message type and version, and exports the result as JSON.
Parse an HL7 v2 message
Runs entirely in your browser. The message is not uploaded, logged or stored, and it is discarded when you leave or reload the page. Use synthetic or de-identified data when you can.
Paste one message. Segments may be separated by CR, LF or CRLF.
Paste a message or load a sample to see its segments and fields.
How to read an HL7 v2 message
An HL7 v2 message is plain text. Each line is a segment, and its first three characters name it: MSH for the message header, PID for patient identification, PV1 for the visit, OBR and OBX for orders and results. The standard ends each segment with a carriage return; files, e-mails and log viewers often turn it into a line feed, which is why this parser accepts both.
Inside a segment, fields are separated by the pipe character and numbered from 1, so PID-5 is the fifth field after the segment name: the patient name. MSH is the exception. Its first field, MSH-1, is the field separator itself, and MSH-2 holds the encoding characters, usually ^~\&. Counted that way, MSH-9 is the message type and trigger event, MSH-10 the control ID and MSH-12 the version.
The encoding characters define the lower levels. A caret (^) separates components, so DOE^JANE is a family name followed by a given name. A tilde (~) separates repetitions, which is how PID-3 carries several patient identifiers. An ampersand (&) splits a component into subcomponents, and a backslash (\) starts an escape sequence such as \T\, which stands for a literal ampersand inside text.
When an interface rejects a message, read MSH-9 and MSH-12 first, then compare the field named in the error with the partner’s interface specification. Field positions stay backward compatible across 2.x versions, because new fields are added at the end, but optionality, lengths and code tables vary by version and by site.
Further reading
Frequently Asked Questions
Is my HL7 message uploaded or stored?
No. The parser is JavaScript that runs in your browser tab. The message is not sent to a server, logged or saved, and it disappears when you close or reload the page. The input and results are also marked to be excluded from optional session recordings. Even so, prefer synthetic or de-identified messages.
Which HL7 versions does the parser support?
Any HL7 v2.x message that uses the standard delimiter syntax, including custom delimiters declared in MSH-1 and MSH-2. Field names follow HL7 v2.5.1 for common segments such as MSH, PID, PV1, ORC, OBR and OBX. HL7 v3, CDA documents and FHIR resources use XML or JSON and are not parsed here.
Can I convert HL7 to JSON?
Yes. After parsing, choose Copy as JSON. The output lists each segment with its non-empty fields, field names where known, the decoded value, and repetitions as arrays of components. It is a readable structure for debugging and tests, not an HL7 or FHIR standard format.
Need an HL7 interface built or fixed?
Help is available for HL7 v2 and FHIR interfaces: message mapping, Mirth Connect channels, acknowledgements and error handling.