HL7 transport utility
Inspect HL7 v2 MLLP streams, validate VT–FS–CR boundaries, extract individual messages, display invisible control characters, view raw bytes, or wrap plain HL7 in MLLP.
Inspector and encoder
Use raw control characters, visible tokens such as <VT> and <FS>, escaped notation such as \x0B, or a hex byte sequence.
Raw VT, FS, and CR characters may be invisible in the input box. The output views make them explicit.
Stream diagnostics will appear here.
HL7 payload will appear here.
Visible control characters will appear here.
Escaped MLLP will appear here.
Hex bytes will appear here.
Frame diagnostics will appear here.
Supported in this version
Detects the MLLP start block VT (0x0B), end block FS (0x1C), and required trailing CR (0x0D).
Splits multiple frames from one pasted stream and lets you inspect each payload separately.
Accepts raw controls, \xNN/\uNNNN escapes, visible VT/FS/CR tokens, and hexadecimal bytes.
Summarises MSH message type, control ID, version, segment count, and CR versus CRLF/LF line endings.
Wraps plain HL7 with VT … FS CR, normalises segment separators to CR, and unwraps the selected frame.
No network connection, socket testing, TLS, character-set conversion beyond UTF-8 display, or site-specific interface-profile validation.
FAQ
A normal frame begins with VT (0x0B), contains the HL7 payload, ends with FS (0x1C), and is immediately followed by CR (0x0D). The HL7 payload itself normally uses CR between segments.
VT, FS, and CR are control characters and are usually invisible in ordinary text boxes. Use Visible controls, Escaped frame, or Hex dump to see them explicitly.
The frame terminator is FS followed by CR. HL7 v2 segment separators are also normally CR. Some systems add LF characters, which this tool preserves and flags for review.
No. It is a local framing and byte-inspection tool; it does not open a TCP connection or transmit messages.
No. Use synthetic, anonymised, or test data only.
Practical guide
MLLP is a lightweight byte-framing convention commonly used to carry HL7 v2 messages over a TCP connection. It defines where a message begins and ends; it does not define the HL7 fields, acknowledgement meaning, socket lifecycle, retries, or encryption.
0x0B, often displayed as <VT>.0x0D between segments.0x1C, displayed as <FS>.0x0D, displayed as <CR>.Worked example
<VT>MSH|^~\&|SENDER|FACILITY|RECEIVER|FACILITY|...<CR>
PID|1||12345^^^HOSPITAL^MR||TEST^ALEX<CR><FS><CR>
Hex boundaries: 0B ... 1C 0DThe carriage return before FS terminates the final HL7 segment and is part of the payload. The carriage return after FS terminates the MLLP frame. They serve different purposes even though both use byte 0x0D.
Troubleshooting
0x0B when the receiver expects MLLP.A TCP read can return part of a frame, one frame, or several frames. Correct receivers buffer bytes until a complete MLLP boundary is available. A packet capture may therefore look incomplete even when the full application stream is valid.
This browser tool inspects supplied data; it does not open a TCP socket, test TLS, measure network timing, or prove how the remote endpoint buffers and acknowledges messages.
Authorship and review
Maintained and technically reviewed by Health Data Tools, drawing on more than 15 years of healthcare integration experience across HL7, FHIR, CDA, APIs, PKI, and clinical integration systems.
Technically reviewed:
Official references
These references support the technical context. Local implementation guides, vendor profiles, and receiving-system rules still take precedence for a specific interface.