There are two ways for a client to get data from an OPC server: know the exact identifier of the point you want in advance, or explore the server to find out what it offers. Tag browsing is the second - walking the server's structure to discover which tags and nodes exist before committing to read any of them. This guide explains what browsing does, how it differs from subscribing to known identifiers, why very large address spaces make browsing slow, and how integration tools lean on browse to build their mappings. It complements pages on node identifiers and the address space by focusing on the act of discovery itself.
Tag Browsing in one line: Tag browsing is the act of navigating an OPC server's address space to discover the tags, nodes, and structure it exposes, rather than accessing points by identifiers already known in advance. In OPC UA it uses browse services to walk the hierarchy of nodes and their references, letting a client enumerate what is available. Browsing is about discovery, whereas subscribing is about receiving updates from points you have already identified.
An OPC UA server organizes everything it exposes into an address space: a connected graph of nodes, where each node has an identifier and nodes are linked by references that express structure, such as one node organizing several others beneath it. Browsing is the operation of following those references to move through the graph. A client starts at a known entry point, asks the server what that node references, receives the list of connected nodes, and can then browse into any of them in turn, effectively walking the tree of folders, objects, and variables the server holds. The result is a picture of what the server offers, built by exploration rather than assumed in advance.
This matters because the alternative requires foreknowledge. To subscribe to a point without browsing, a client must already know that point's exact node identifier - and identifiers can be opaque, server-specific, and not something a human would guess. Browsing removes that requirement: an engineer or a tool can connect to an unfamiliar server and discover its contents, learning both the identifiers it needs and the human-readable names and structure that make those identifiers meaningful. Browsing typically returns not just the identifier of each node but its display name, its type, and whether it is a folder to descend into or a variable to read, which is what lets a person recognize the tag they are looking for.
Browsing and subscribing are therefore sequential phases of the same overall task. Browse is the discovery step that answers what is here and what is it called; subscribe is the runtime step that says now send me updates for these specific points as they change. A client usually browses once, during setup or configuration, to establish which nodes it cares about, and then subscribes to those nodes for ongoing data. Confusing the two leads to inefficiency - browsing repeatedly at runtime when the structure is already known, or hard-coding identifiers when discovery would have been more robust to change.
Browsing is inherently a traversal, and traversals get expensive as the thing being traversed grows. A server exposing tens of thousands or hundreds of thousands of nodes presents an address space that takes many round trips to walk fully, because each browse request returns the children of one node and the client must issue further requests to descend into each of those. Fully enumerating a deep, wide namespace can mean a very large number of exchanges with the server, and the client accumulates and holds a great deal of structural information as it goes. The cost is not in reading values - it is in the sheer number of navigation steps required to map everything out.
Several factors compound this. Servers often return browse results in limited batches, so a node with many children yields its children over several continuation requests rather than all at once, multiplying the exchanges. Network latency to a remote or field-located server turns each round trip into a real delay, so a browse that is instant on a local server becomes sluggish over a constrained link. And a client that re-browses the entire address space every time it needs anything, instead of caching the structure it already discovered, pays that traversal cost repeatedly. For these reasons, full browses are usually a configuration-time activity, done once and cached, rather than something repeated during normal operation.
Well-behaved clients mitigate the cost by browsing selectively and lazily. Rather than eagerly enumerating an entire large namespace up front, they browse only the branches an engineer is currently exploring, expanding a folder only when it is opened, and they cache what they have already learned so they do not re-walk it. This keeps browsing responsive even against big servers, because at any moment the client is only navigating a small local region of the address space rather than the whole of it.
When an integration or cloud SCADA connects to an OPC server, one of its first jobs is to figure out what that server exposes, and browse is how it finds out. An engineer configuring the connection typically browses the server's address space in the tool, expanding folders and objects to locate the tags that matter, and selects them for import. The tool records each selected node's identifier along with its name, type, and units, and uses those to build the mapping between the source server's points and the platform's own tags. Browse is what makes this a point-and-select exercise rather than a matter of hand-typing opaque identifiers.
Browsing also supports discovery of new points over time. When a server's address space changes - a device is added, or new tags appear - re-browsing reveals what is now present that was not before, so an integration can surface newly available points for an engineer to map rather than requiring someone to know about them out of band. This auto-discovery is a large part of why browse-capable servers are pleasant to integrate: the tooling can keep pace with a changing field by re-examining the server rather than depending on external documentation of what exists.
A cloud SCADA such as Merobix benefits directly from this discovery model when it ingests data over OPC UA. Browsing the source server lets the platform present an engineer with the actual tags a device exposes, which are then selected and mapped into the platform's canonical tag identities for monitoring, alarming, and history. Because browse yields human-readable names and structure alongside the raw identifiers, that mapping step can be quick and accurate, and re-browsing later keeps the platform aware of new points as the field evolves - turning the server's own self-description into the starting point for a clean, maintained integration.
Browsing is discovery - navigating a server's address space to find out which tags and nodes exist and what they are called. Subscribing is runtime data delivery - asking the server to send updates for specific points you have already identified. A client usually browses once during setup to decide which nodes it cares about, then subscribes to those nodes for ongoing values.
Browsing is a traversal, and each browse request returns the children of only one node, so mapping a namespace with hundreds of thousands of nodes takes many round trips. Batched results, network latency to remote servers, and clients that re-browse instead of caching all compound the cost. Full browses are therefore usually a one-time configuration activity, with structure cached and only sub-branches expanded on demand.
They browse the source server's address space so an engineer can expand folders, find the relevant tags, and select them for import instead of hand-typing opaque identifiers. The tool records each node's identifier, name, type, and units to build a mapping into the platform's own tags. Re-browsing later surfaces newly added points, keeping the integration aware of changes in the field.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.