A browser can tell the server explicitly which encoding is used thanks to Content-type header. Content-type might contains charset, but it's possible to infer the encoding by type. For example, application/json:
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.
What about the situation that Content-type is not defined in request?
A sender that generates a message containing a payload body SHOULD
  generate a Content-Type header field in that message unless the
  intended media type of the enclosed representation is unknown to the
  sender. If a Content-Type header field is not present, the recipient
  MAY either assume a media type of "application/octet-stream"
  ([RFC2046], Section 4.5.1) or examine the data to determine its type.