Status code · Data access
BadDataEncodingInvalid
BadEncoding
BadDataEncodingInvalid means the DataEncoding QualifiedName in your Read or monitored item does not belong to that node's DataType. Leave DataEncoding empty to get the server's default, or browse HasEncoding from the DataType node to find the encoding names it really offers.
Defined behaviour: The data encoding specified in the request is not valid for the node - the encoding does not identify a known encoding of that node's DataType. (our description of the condition this code reports)
What you actually see
A Read or CreateMonitoredItems on a structured variable fails with BadDataEncodingInvalid while scalar nodes on the same server read fine.
Why it happens
- DataEncoding set to a name the DataType does not haveDataEncoding is a QualifiedName on the ReadValueId, normally Default Binary, Default XML or Default JSON. It must be one of the encodings actually attached to that DataType by HasEncoding references. Spelling it differently, using the wrong namespace index on the QualifiedName, or copying an encoding name from another type all produce this code.
- An encoding requested that the server does not define for that typeA server may define only Default Binary for its custom structures. Asking for Default XML or Default JSON is then invalid rather than merely unsupported, because there is no encoding node to identify.
- DataEncoding supplied for a non-structured nodeBuilt-in scalar types have no alternative encodings. Setting a DataEncoding on a read of a Double or a String is not meaningful and servers reject it. Clients that set a global default encoding across every read hit this on the scalar members of a batch.
- Encoding NodeId taken from a stale namespace indexEncoding nodes live in the vendor namespace and their NodeIds move when the namespace index shifts. A client that cached the encoding NodeId rather than resolving its namespace URI at connect time sends an id that now points elsewhere or nowhere.
- Client built the encoding name from the DataType browse nameThe encoding node's BrowseName is not the DataType's BrowseName. Deriving one from the other is a guess that happens to work on some servers and fails on others, which is why the same client code is portable until it is not.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Leave DataEncoding unset and retryAn empty DataEncoding tells the server to use its default for that node. Unless you have a specific reason to force an encoding, this is correct and portable. Most occurrences of this code are a client setting an encoding it did not need to set.
- Browse HasEncoding from the DataType nodeRead the node's DataType attribute to get the DataType NodeId, then browse forward HasEncoding references from it. The targets are the encoding nodes, and their BrowseNames are exactly the values DataEncoding will accept.
- Resolve namespace indexes at connect timeRead the NamespaceArray, map the vendor namespace URI to its current index, and rebuild any cached encoding NodeIds and QualifiedNames from the URI. Never persist a raw namespace index for an encoding node.
- Drop DataEncoding for scalar nodesApply an encoding only to nodes whose DataType is a structure. If your client sets a default DataEncoding on every ReadValueId, make it conditional on the node actually having encodings.
- Confirm the encoding survives into the monitored itemThe monitored item create request carries its own ReadValueId with a DataEncoding field. Fixing the read path does not fix the subscription path; check both.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UaExpert | Reads use the default encoding unless you change it. If a structured node reads in UaExpert but not in your client, your client is setting a DataEncoding that UaExpert leaves empty - that comparison is the fastest diagnosis available. |
| asyncua (Python) | The ReadValueId has a DataEncoding field that defaults to an empty QualifiedName. Setting it by hand to a namespace 0 QualifiedName is a common mistake, because the encoding node for a vendor type lives in the vendor namespace. |
| node-opcua | readValue accepts a dataEncoding on the ReadValueId. Leave it undefined. The client resolves custom structure encodings itself once the data type manager has loaded the server's type information. |
| UA-.NETStandard (C#) | ReadValueId.DataEncoding is a QualifiedName and should normally be left null. The complex type system loads encodings from the server, so forcing one manually usually fights the SDK rather than helping it. |
| open62541 (C) | UA_ReadValueId has a dataEncoding member; the convenience read functions leave it empty. Custom structures are returned as ExtensionObjects with the encoding id the server chose. |
| OPC Publisher | Per-node configuration can request an encoding. Where a server offers only binary encodings for its structures, asking for another one fails at monitored item creation and the node never publishes. |
What it looks like in the log
Read ns=5;s=Recipe returned BadDataEncodingInvalid (requested Default JSON)
ServiceFault: BadDataEncodingInvalid - no encoding named Default XML for that DataType
CreateMonitoredItems item 3: BadDataEncodingInvalidConfirm the fix
Read the node with the corrected or empty DataEncoding and confirm the returned value decodes into a real structure rather than an opaque ExtensionObject.
Stop it happening again
Do not set DataEncoding in client configuration unless a specific requirement demands it, and resolve every encoding NodeId from its namespace URI at connect time so a namespace reindex after a server upgrade cannot invalidate it.
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.