Kaiser Ludi once said

There is no hard size-limit for messages at all.

Single entries like strings or arrays () are limited to short.Max character/elements in with the exception of flat (not jagged) byte arrays, that are limited to int.Max entries).
Note that for jagged arrays the limit is per array, so you could have i.e. something like this: arr[10000][10000][10000] and would not violate the limits at all.
Also note that the limit is for the element count, not for the size in byte, so a double-array with short.max bytes would be 32*8==256kb in size and still within the limits.

For UDP connection we use a MTU of 1200, which means that when an enet command including overhead for the protocols (udp, enet, photon itself) gets bigger than 1200 bytes, it will be fragmented into multiple udp packets. So one could say there is a soft limit of about roughly 1000 bytes of actual payload until which ones can assume that the message will not get fragmented.

The clients do not work too well with UDP connections for packages beyond about 100kb, as they are not optimized for handling that amount of fragments for a single message.

The servers buffer size per client is limited to a value that con be configured in its config-file. However as you can't modify the content of that file in Photon Public Cloud, this means  a hard limit for the message size on Photon Cloud, which is currently 500kb.

The C++ Clients happily manage to send and receive messages that are several MB in size, when TCP is used and when they connect to a Photon server instance, which has it buffersizes configured to a high enough value.
Such several MB messages actually get sent by an Enterprise customer in production.
Values above 10MB are untested.

At some point in the hundreds of MB or in the GB a client or even a server might simply run out of resources.

The C# clients are not tested with such messages sizes and may run into problems at any point beyond 100kb.


So message sizes far beyond 32kb do actually work in production and this is used by lots of customers for initial messages after entering a room and internal messages can also often get that big (initial room list event in the LoadBalancing lobby with high CCU counts and intensive use of custom properties that are shown in the lobby are prone to this). This is discouraged, but prohibiting it doesn't really help: if one 200kb message is not allowed, people will just queue in 10 20kb messages at once, which isn't really to much better.