MessagePack Validator
Paste hex or base64 MessagePack and check whether it parses cleanly. See byte count, top-level type, and the parser error verbatim if it fails.
What is the MessagePack Validator?
You're integrating with a service that emits MessagePack and the wire format keeps surprising you — wrong byte count, weird trailing bytes, the parser dies cryptically with no clue which field broke. This tool takes a hex or base64 dump of a MsgPack payload, runs it through a real decoder, and tells you what actually came out the other side.
We pipe your input through @msgpack/msgpack's decoder. If it parses, we tell you the byte count, the top-level type (map, array, string, int…), and the key or array length so you can sanity-check it against the schema in your head. If it fails, we surface the parser's error message verbatim — it usually points right at the offset that broke.
Hex and base64 are auto-detected. Whitespace, commas, 0x prefixes, and \xNN escapes are tolerated, so you can paste straight from a Wireshark capture, a server log, or a Python repr() dump. Nothing leaves your browser — the decoder runs locally.
How to Use the MessagePack Validator
Paste it in. The validator runs on every keystroke (debounced 300 ms) so you don't hit a button.
Paste Hex or Base64 MsgPack
Drop your encoded payload into the left pane. Hit Sample MsgPack to load a small order object encoded as hex — handy when you just want to see what a valid result looks like. The decoder follows the MessagePack spec, so anything a conformant encoder produced will round-trip cleanly. Example hex (a single int 1):
01That's the wire byte for positive fixint 1. Bigger payloads — maps, arrays, strings — start with format bytes like 0x80–0x9f (fixmap/fixarray) or 0xa0–0xbf (fixstr).
Read the Validation Report
The right pane fills in automatically. On success you get a small report — detected input format (hex or base64 per RFC 4648), encoded byte count, top-level type, key/array count, plus a JSON preview of the decoded value (truncated at 2 KB so the pane stays readable).
Investigate Failures
On a parse failure the right pane shows ✗ Invalid MessagePack followed by the decoder's error string. Common ones: "Insufficient bytes" (your hex got truncated), "Unrecognized type byte" (you pasted JSON or text by mistake, or the input is corrupted), and "Extra bytes were found" (a length prefix or framing byte slipped in). Treat the underlying byte stream as a Uint8Array in your head — most failures are framing or length problems, not encoding bugs.
When You'd Actually Use This
Debug a Cache Miss
Your Redis key holds a MessagePack-encoded order (orderId: 'ORD-7421', items, customer) and the consumer is throwing on deserialize. Paste the hex from redis-cli --no-raw GET, see whether the wire format is even valid, and confirm the top-level type matches what your decoder expects.
Validate Wire Capture
You captured a frame off the network with Wireshark or tcpdump, exported the bytes, and want to know if the MsgPack inside is well-formed before you hand-trace the framing. Paste, glance at the type and byte count, move on.
Sanity-Check a Producer
Wrote a custom encoder in Go or Rust? Encode a known fixture ({sku: 'SKU-101', qty: 2}), dump it as hex, and paste it here. If we read it back as the same map you wrote, your encoder is conformant against the MessagePack format.
Pre-flight Before a Bug Report
Filing an issue against an upstream library? Confirm the payload is actually valid MsgPack first — half the "library bug" reports are malformed input. A 30-second paste here saves a back-and-forth.
Common Questions
Does the payload leave my browser?
No. Decoding runs in JavaScript on this page using the @msgpack/msgpack decoder. Nothing is uploaded, logged, or sent to a backend — close the tab and the data is gone. Same model as a desktop hex viewer, just in your browser.
Does it accept binary file uploads, or only hex/base64?
Hex and base64 only. Browsers don't expose file bytes to the page without a file picker, and most copy-paste workflows already produce hex (from xxd, hexdump -C, debugger tooltips) or base64 (from REST API responses, log lines). If you have a raw .msgpack file, run xxd -p file.msgpack or base64 file.msgpack first.
How does it tell hex from base64?
Hex is detected first: if the input (after stripping whitespace, commas, 0x prefixes, and \xNN escape sequences) is all hex characters and even-length, we treat it as hex. Otherwise we hand it to atob as base64. The "Detected input format" line in the report tells you which path was taken — useful when an ambiguous string like deadbeef happens to be valid in both encodings.
Why does it sometimes say "Extra bytes were found"?
MessagePack streams should be exactly one top-level value. If you pasted a length-prefixed frame (e.g. a 4-byte big-endian length added by a framed transport protocol) or two concatenated payloads, the decoder reads the first value and complains about the leftover. Trim the framing or split into individual messages.
Can it decode MessagePack extensions (timestamp, custom types)?
The default @msgpack/msgpack decoder handles the built-in timestamp extension type (-1) out of the box and shows it as a JS Date in the preview. Custom extension types (0 through 127) decode to a generic {type, data} shape — the validator will still report the payload as valid, but you'll need your own ExtensionCodec to interpret the contents.
What's the difference between this and the MessagePack Viewer?
The Viewer is for browsing — it shows a tree-style breakdown of every key and value. This Validator is for the "is it even valid?" question — quick yes/no plus byte count and top-level type. If the validator says it parses and the type is right, switch to the Viewer to actually read the contents.
Other MessagePack Tools
Once you've confirmed the payload is valid, these tools take it the rest of the way: