Input

Output

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, you get the byte count, the MessagePack type of the top-level value (map, array, str, int, float, bin...), and the key or element count, so you can sanity-check it against the schema in your head. If it fails, you get a plain-English explanation plus the byte offset when the decoder reports one, for example where a complete value ended and leftover bytes began.

Hex and Base64 (including URL-safe Base64) are auto-detected. Whitespace, commas, 0x prefixes and \xNN escapes are tolerated, and escaped byte strings that mix \xNN with plain text, like a Python repr() of bytes (b'\x82\xa7orderId...') or redis-cli output, are read byte by byte. 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, and 64-bit integers are kept exact in the preview rather than rounded. Example hex (a single int 1):

That'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 an explanation. The common ones: the bytes run out before the value is complete (your hex got truncated), an unrecognized type byte (you pasted JSON or text by mistake, or the data is corrupted), and extra bytes after a complete value (a length prefix, framing byte, or a second message slipped in). Treat the 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 text only, there's no file picker on this page yet. 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 and paste the result.

How does it tell hex from base64?

Hex is checked first: if the input (after stripping whitespace, commas, 0x prefixes and \xNN escapes) is all hex characters and even-length, it's treated as hex. Otherwise it's decoded as Base64, and -/_ are accepted for URL-safe Base64. The "Detected input format" line in the report tells you which path was taken, which helps when a string like deadbeef happens to be valid in both encodings.

Why does it say extra bytes follow the value?

A MessagePack payload here 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) or two concatenated payloads, the decoder reads the first value and reports the leftover bytes and the offset where they start. Trim the framing or split it 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?

Both decode the same way. The Viewer shows the whole decoded value as indented JSON so you can read it. This Validator answers "is it even valid?" with a short report: input format, byte count, top-level type and key count, plus a preview cut at 2 KB. If the validator says it parses and the type is right, switch to the Viewer to read the full contents.

Other MessagePack Tools

Once you've confirmed the payload is valid, these tools take it the rest of the way: