Status code · Data access
BadEncodingLimitsExceeded
BadMessage limits
BadEncodingLimitsExceeded means a message hit a stack encoding limit: MaxMessageSize, MaxChunkCount, MaxArrayLength, MaxStringLength or MaxByteStringLength. It is enforced on both sides, so raise the limit on whichever end is complaining, or split the operation into smaller batches - usually the better fix.
Defined behaviour: The message encoding or decoding limits imposed by the stack have been exceeded - the encoded form of the message exceeds a configured size, array length, string length or nesting limit. (our description of the condition this code reports)
What you actually see
Reads or subscription notifications work for small sets and fail once a batch grows, a large array is added, or an address space export is attempted.
Why it happens
- Batch too large for the encoded messageA Read or Write with a few thousand nodes, or a BrowseResult carrying many references, encodes to more than the configured MaxMessageSize or needs more chunks than MaxChunkCount allows. The service is legal; the encoded message is not.
- A single large array or ByteString valueMaxArrayLength and MaxByteStringLength are separate from the message size. A trend buffer, an image, a file transfer chunk or a NodeSet blob can exceed the array or byte-string limit on its own, so no amount of batch reduction helps until that specific limit is raised.
- Notification message too large for a Publish responseWhen many monitored items report in the same publishing cycle, the NotificationMessage grows accordingly. Deep queues that all drain at once produce a burst that exceeds the encoding limit, which is why the failure correlates with a process event rather than with steady-state load.
- Client and server limits configured differentlyLimits are negotiated per direction in the Hello and Acknowledge exchange, and stacks apply their own local decoding limits on top. A server that accepts a large request may still be unable to encode a large response if the client advertised a small receive buffer.
- Deeply nested or self-referencing structuresSome stacks impose a nesting depth limit on encoded structures and Variants. A structure containing arrays of structures several levels deep can trip a depth limit at a size well under the message limit.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Establish which side and which limit is complainingThe client log usually says whether the failure happened while encoding a request or decoding a response. If the client fails to decode, its own limits are too small; if the server faults, the request was too large for it. Fixing the wrong side changes nothing.
- Reduce the batch before raising any limitSplit large Reads, Writes and Browses into chunks of a few hundred operations. Respect the server's own MaxNodesPerRead, MaxNodesPerWrite and MaxNodesPerBrowse from the ServerCapabilities OperationLimits object, which is the supported way to size batches.
- Cap notification volume per PublishSet MaxNotificationsPerPublish on the subscription so the server spreads a burst over several responses instead of building one oversized message. Combine this with sane QueueSize values rather than leaving queues deep.
- Raise the specific limit that is actually bindingIf a single large array is the problem, raise MaxArrayLength or MaxByteStringLength on the client and, where configurable, on the server. Raising MaxMessageSize alone does not lift an array-length limit.
- Use continuation-based services for bulk operationsBrowse with MaxReferencesPerNode plus BrowseNext, and HistoryRead with continuation points, exist so bulk results can be paged. Trying to pull everything in one call is what pushes you into the limits in the first place.
- Consider a file transfer or NodeSet export for very large payloadsFor address space dumps and large binary content, the FileType interface or an offline NodeSet2 export is the right mechanism. Reading a multi-megabyte ByteString through a normal Read is fighting the transport.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | TransportQuotas carries MaxMessageSize, MaxBufferSize, MaxArrayLength, MaxStringLength and MaxByteStringLength on both client and server configuration. Raising the server value without raising the client value leaves the failure exactly where it was. |
| open62541 (C) | UA_ClientConfig and UA_ServerConfig expose maxMessageSize, maxChunkCount and the per-type decoding limits. The defaults are deliberately conservative for embedded targets and are frequently the binding constraint on a desktop client. |
| node-opcua | Set maxMessageSize and maxChunkCount in the connection strategy or endpoint options. Large browse results are the usual trigger; use browseNext rather than a single large browse. |
| asyncua (Python) | Read OperationLimits from Server_ServerCapabilities_OperationLimits and chunk your reads to match. asyncua does not chunk automatically, so a list comprehension over ten thousand nodes goes out as one request. |
| UaExpert | Exporting a large address space or reading a large array can hit the client's own decoding limits, shown in the Log view. That failure is client-side and tells you nothing about whether the server could have served it. |
| OPC Publisher | Message size limits apply both to the OPC UA session and to the outgoing broker message. A batch of monitored items that encodes cleanly to the server can still exceed the broker payload limit downstream, so check which hop failed. |
What it looks like in the log
BadEncodingLimitsExceeded while decoding ReadResponse - array length 120000 exceeds MaxArrayLength 65535
ServiceFault: BadEncodingLimitsExceeded on Browse with 5000 nodes
Encoding limits exceeded: message would require 12 chunks, MaxChunkCount is 8Confirm the fix
Re-run the operation at the reduced batch size and confirm it succeeds, then step the batch size up until you find the real ceiling and set your production batch comfortably below it.
Stop it happening again
Read Server_ServerCapabilities_OperationLimits at connect time and derive batch sizes from it rather than hard-coding them. Cap MaxNotificationsPerPublish on every subscription so a process upset cannot generate an unencodable notification.
Related status codes
Concepts on this page
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.