The header just denotes what the content is encoded in. It is not necessarily possible to deduce the type of the content from the content itself, i.e. you can’t necessarily just look at the content and know what to do with it. That’s what HTTP headers are for, they tell the recipient what kind of content they’re (supposedly) dealing with.
Content-type: application/json; charset=utf-8 designates the content to be in JSON format, encoded in the UTF-8 character encoding. Designating the encoding is somewhat redundant for JSON, since the default (only?) encoding for JSON is UTF-8. So in this case the receiving server apparently is happy knowing that it’s dealing with JSON and assumes that the encoding is UTF-8 by default, that’s why it works with or without the header.
Does this encoding limit the characters that can be in the message body?
No. You can send anything you want in the header and the body. But, if the two don’t match, you may get wrong results. If you specify in the header that the content is UTF-8 encoded but you’re actually sending Latin1 encoded content, the receiver may produce garbage data, trying to interpret Latin1 encoded data as UTF-8. If of course you specify that you’re sending Latin1 encoded data and you’re actually doing so, then yes, you’re limited to the 256 characters you can encode in Latin1.