"I would expect ..." that's the problem. Expectations fail when both sides don't have the same expectations. As there is no way in JSON to specify what type a f

"I would expect ..." that's the problem. Expectations fail when both sides don't have the same expectations. As there is no way in JSON to specify what type a field is and as dates aren't even specified in the JSON, you aren't sure if dates are in epoch time or any common or uncommon variant of ISO 8601 (or worse, non of these two options). JSON hasn't been designed for binary data, so it's not surprising that it lacks a binary data type. There are several options besides base64, you could e.g. use yEnc or BSON. But unless you have really large binary data (in that case I would instead of embed it in JSON, only embed an URL in JSON and let the client download the data separately), I wouldn't bother with another encoding than base64. It is easily compressable and this is handled transparently, so you reach such a low overhead that it is hard to justify using a non-standard option like yEnc.