NetworkX node-link

NetworkX node-link is a JSON serialization for graphs produced by the nodelinkdata function in the NetworkX Python library and read back by its companion nodelinkgraph. It is not a formally standardized file format but a de facto convention: a plain dictionary that any JSON tooling can emit or parse, designed originally to feed graph data to JavaScript visualizations such as D3.js. NetworkX ships it in the networkx.readwrite.json_graph package alongside sibling encodings for adjacency, tree, and Cytoscape data.

The data model is a single top-level object with the boolean flags "directed" and "multigraph", a "graph" dictionary holding graph-level attributes, a "nodes" array, and an edge array. Each node object carries an "id" identifier plus any arbitrary node attributes as extra keys; each edge object carries "source" and "target" endpoints referencing node ids, an optional "key" (used only for multigraphs to disambiguate parallel edges), and any edge attributes inline. This attribute-passthrough design lets nodes and edges hold rich typed payloads without a schema, which is the format's main appeal for property-graph style data.

A notable versioning wrinkle affects interoperability. Historically the edge array key was "links" (controlled by a link keyword argument); NetworkX 3.4 deprecated that argument, introduced an explicit edges parameter, and 3.6 removed the old link kwarg and made "edges" the default key name. Files written by different NetworkX versions may therefore place edges under "links" or "edges", and round-tripping requires that nodelinkdata and nodelinkgraph be called with matching key-name arguments (source, target, name, key, nodes, edges). All attribute keys are coerced to strings for JSON compliance, and the function raises an error if source, target, and key tuples are not unique.

Strengths are simplicity, human readability, and zero-friction integration with the wider Python graph ecosystem, since NetworkX also imports and exports formats like GraphML, GEXF, GML, and Pajek. Limitations include the absence of a versioned specification, the "links"/"edges" naming drift that breaks naive consumers, no typing or schema validation, and verbosity compared with binary or adjacency encodings. For richer, standardized JSON graph interchange, alternatives such as Cytoscape JSON, JGF 2.0, or GraphSON are often preferred.