JSON vs. XML vs. YAML: A Performance and Use-Case Comparison (2025)

The choice of a data serialization format is a critical architectural decision, influencing system performance, developer workflow, and long-term maintainability. While binary formats like Protocol Buffers and Apache Avro dominate high-throughput, internal machine-to-machine communication, text-based formats—JSON, XML, and YAML—remain essential for human interaction, configuration management, and external API interfaces. This report provides a deep technical comparison of these three dominant formats, analyzing their trade-offs in performance, structural complexity, and domain-specific utility as of 2025.

I. Foundational Comparison: Syntax and Structural Overhead

The structural design of a serialization format dictates two fundamental properties: how easily a human can read and modify the data, and the inherent bandwidth required to transmit the data.

1.1 Readability and Human-Editing Trade-offs

The design philosophies behind JSON, XML, and YAML diverge significantly regarding human accessibility.

YAML (Human-Centric Design): YAML (YAML Ain’t Markup Language) was engineered to prioritize human readability above all else. Its structure is based on indentation and minimal structural punctuation, often resembling how one might naturally transcribe structured data.[1] This minimalist syntax reduces visual clutter and makes large configuration files easier to navigate.[2] Crucially, YAML supports native features essential for human editing, such as comments (#), which allow developers to document complex configuration logic directly within the file, a capability entirely absent in JSON.[2] This is a decisive factor favoring YAML in DevOps and infrastructure contexts.

JSON (Structured Simplicity): JSON (JavaScript Object Notation) achieves simplicity through universality, but not necessarily maximized readability. While cleaner than XML, JSON relies on explicit delimiters: mandatory quotation marks for string keys and values, curly brackets ({}) for objects, and square brackets (“) for arrays.[1] These delimiters provide explicit scope definition, which simplifies machine parsing but introduces visual noise compared to YAML’s whitespace structure. The reliance on explicit, rigid syntax aids automated tooling and syntax checking, making it robust for machine generation and consumption.

XML (Extreme Verbosity): XML (Extensible Markup Language) is the most challenging format for manual creation and human reading. Its reliance on verbose, repetitive opening and closing tags (e.g., and ) creates substantial syntactic overhead.[4] This structural complexity increases the cognitive load for developers attempting to read or debug complex XML documents manually.

1.2 File Size Metrics and Bandwidth Efficiency

File size directly impacts network latency and storage cost, making it a primary performance consideration for high-volume data exchange.

JSON (Minimal Overhead): JSON is generally the most compact format. Its simple syntax and lack of mandatory closing tags ensure high data density.[4] This minimal overhead results in reduced file sizes, which translates directly to faster data transmission speeds, making JSON the format of choice for bandwidth-sensitive applications, particularly across the public internet.[4]

XML (Maximum Overhead): XML documents inherently carry the maximum overhead. The necessity of repeating the element name in both the opening and closing tags results in substantial redundancy.[5] This repetitive structure causes XML documents to be significantly larger than their YAML or JSON counterparts, increasing bandwidth consumption and requiring more compute resources for parsing.[5]

YAML (Efficient Data Reuse): While YAML’s indentation structure uses more bytes than JSON’s delimited structure, it possesses an advanced feature that can dramatically increase logical efficiency: the use of anchors and aliases (references).[3] This powerful reference mechanism allows complex data objects (or blocks of configuration) to be defined once (the anchor) and referenced multiple times throughout the document (the alias).[5] For datasets or configurations containing significant data duplication, this feature avoids the physical redundancy required in JSON, potentially making the YAML document logically smaller and more maintainable, though not necessarily smaller in raw byte size unless compressed.

II. The Performance Imperative: Parsing Speed and Efficiency

For senior architects, performance is often determined by parsing speed and memory consumption. Benchmarks consistently show a clear hierarchy defined primarily by the complexity of the format’s accepted grammar.

2.1 Comparative Benchmarks: The Speed Advantage of Trivial Grammar

JSON’s Dominance: JSON is consistently the fastest format to parse and generate.[8] Its foremost design goal is simplicity and universality, resulting in an exceptionally concise and well-defined grammar.[9] This simplicity minimizes the complexity required for lexical and syntax analysis, leading to minimal overhead during machine processing.

Modern JSON libraries leverage advanced optimization techniques. High-performance parsers, such as simdjson, utilize hardware capabilities like Single Instruction, Multiple Data (SIMD) instructions to process JSON data at exceptionally high throughputs, achieving parsing speeds reported to be multiple times faster (e.g., 4x) than conventional production-grade parsers.[10] This raw speed is indispensable for real-time APIs and core system communication.

YAML’s Performance Penalty: YAML generally ranks last or near-last in raw performance benchmarks compared to JSON and sometimes XML.[2] While JSON’s simplicity ensures it is trivial to generate and parse, YAML’s inherent design complexity introduces significant overhead.[9]

2.2 The Cost of Complexity: YAML’s Indentation and Anchor Overhead

The key determinant of parsing speed is not the complexity of the output, but the complexity of the accepted input grammar.[9] YAML’s grammar must handle flexible syntax, strict indentation rules, and, most significantly, the complex internal logic required to resolve anchors and references.[3]

The requirement to handle relational data (anchors) means that YAML parsers often must construct a full representation graph of the data structure during serialization and deserialization.[9] This construction adds overhead, contrasting sharply with JSON encoders, which typically translate native language data types directly into contiguous text chunks. While YAML provides enhanced human readability and functionality, this comes at the direct expense of computing resources and time during parsing.[3]

2.3 XML’s Processing Burden: Tags, Validation, and Namespace Resolution

XML parsing requires substantial computing resources.[5] The sheer volume of tags and symbols in the XML structure increases the base processing cost.[5] Furthermore, XML is rarely used without its supplementary validation and structuring mechanisms, which introduce significant runtime computational taxes. These mechanisms include the need to validate the document against a schema (XSD or DTD) and resolve namespaces, which are non-trivial computational tasks that further degrade overall performance.[8]

2.4 Memory Footprint: Architectural Choices in XML Parsing

For large-scale systems, the method of XML parsing imposes critical architectural decisions concerning memory management, a challenge often avoided when using JSON.

The Architectural Decision Tax: XML processing offers two primary methods: Document Object Model (DOM) and Simple API for XML (SAX).[12]

A DOM parser builds the entire document structure into a tree in memory, allowing for easy, bi-directional navigation and manipulation.[12] However, this leads to a substantial memory footprint, rendering the DOM approach prohibitive for large XML files where memory consumption must be controlled.

An architect dealing with massive XML documents must instead opt for a SAX event-based parser.[12] SAX processes the document sequentially, firing events (e.g., ‘start tag’, ‘end element’) as it reads, using very little memory. While faster at runtime and memory-efficient, SAX sacrifices the ability to easily navigate or modify the document, enforcing a restrictive, streaming, and read-only workflow.[12] JSON’s simpler structure often permits efficient streaming or mapping without forcing such an explicit, high-stakes architectural compromise.

Table 1 provides a synthesis of the key structural and performance metrics comparing the three formats.

Table 1: Technical Comparison of Serialization Formats

Metric	JSON (JavaScript Object Notation)	XML (Extensible Markup Language)	YAML (YAML Ain't Markup Language)
Readability (Human)	Moderate (Rigid use of delimiters)	Low (Extremely verbose, repetitive tags) [5]	Highest (Indentation-based, supports comments) [3]
Parsing Speed	Fastest (Simple, universal grammar) [8]	Slowest (High overhead for validation/namespaces) [8]	Slow (Complex grammar, indentation-sensitive) [3]
File Size/Overhead	Lowest (Minimal syntax) [4]	Highest (Repetitive tagging structure) [5]	Low (Efficient, uses anchors/aliases for reuse) [3]
Schema/Validation	JSON Schema (Structural validation) [8]	XSD/DTD (Strict typing, granular content models) [8]	Limited (Often relies on structural validation) [8]
Native Typing Support	Limited (Basic types only) [6]	Rich (Custom types, dates, namespaces) [6]	Rich (Native dynamic language types, references) [1]

III. Deep Dive into Parsing Logic

The mechanism by which a document is converted into an executable data structure varies significantly based on the format’s grammatical complexity.

3.1 JSON Parsing: Lexical Analysis and Trivial Grammar

JSON parsing follows a highly streamlined, compiler-like structure, tailored for its simple, recursive grammar.

Lexical Analysis (Tokenization): The raw JSON input is first processed by a lexer, or tokenizer. This stage breaks the stream of characters into a sequence of meaningful tokens. These tokens represent the fundamental building blocks of JSON, such as delimiters ({, [, ,), keywords (true, null), and literals (strings, numbers).[13] The simplicity of the JSON character set ensures this stage is rapid and unambiguous.

Syntax Analysis and Object Generation: The parser then consumes the one-dimensional array of tokens and performs syntax analysis.[14] Because JSON is derived from a very small, non-ambiguous subset of JavaScript, the parser’s logic is straightforward. It recursively constructs an Abstract Syntax Tree (AST) that mirrors the hierarchical data structure defined by the tokens. This AST is then directly mapped, or “deserialized,” into the host programming language’s native data structures (e.g., Python dictionaries, Java HashMaps, JavaScript objects).[14] The lack of features like attributes, comments, or references simplifies this entire process, contributing directly to JSON’s performance advantage.

3.2 XML Parsing Architectures: SAX (Event-Driven) vs. DOM (Tree-Based)

XML parsing architectures reflect its origin as a document markup language, necessitating tools capable of handling complex document structures, metadata, and potentially massive file sizes.

SAX (Streaming Event-Based): The Streaming API for XML (SAX) is designed for efficiency in handling large documents.[12] SAX is an event-based parser that reads the XML file sequentially from top to bottom. It does not load the entire document into memory; instead, it triggers callback events (such as startElement, endElement, and characters) as it encounters structural markers.[12] SAX is crucial for applications dealing with documents too large for standard memory allocation, or for applications that only require sequential, read-only access, such as data pipeline logging or message streaming.[12]

DOM (In-Memory Tree): The Document Object Model (DOM) parser represents the entire XML document as a hierarchical tree structure in the system’s memory.[12] This in-memory representation allows developers to navigate the tree easily, both forwards and backwards, and enables simple manipulation, insertion, or deletion of nodes. While powerful for document modification, the DOM’s high memory consumption limits its practical use to smaller documents.[12]

3.3 The Rigor of XML: Validation Mechanisms (DTD and XSD)

XML provides standardized, robust mechanisms for defining and validating data contracts that far exceed the scope and rigor of JSON Schema or basic YAML validation.

XSD Superiority: XML Schema Definition (XSD) offers a detailed mechanism for structural validation.[8] XSD is concerned not only with the data type of scalar values but also with grammatical and content models. For example, XSD can define that a container element must contain an optional header followed by zero or more paragraphs, where each paragraph must be one of three specific types of child elements. This level of granular control over element sequencing and structure is largely absent in JSON Schema, which primarily treats arrays as uniform and homogenous.[15] XSD enables strict typing, required field constraints, and complex content models necessary for high-integrity enterprise data exchange.[8]

The Namespace Mechanism: A core feature of XML is the Namespace. Namespaces are similar in purpose to packages or modules in programming languages, allowing developers to modularize schemas and prevent name collisions when combining elements from different schema definitions.[17] This mechanism is indispensable in enterprise scenarios where data exchange involves integrating several standardized data models, ensuring definitions like “Address” from one schema do not conflict with “Address” from another.[18]

IV. Data Integrity, Typing, and Schema Enforcement

The approaches to data types and schema enforcement reflect each format’s intended use: JSON for universal exchange, YAML for robust serialization, and XML for strict contractual integrity.

4.1 Base Data Type Support: JSON’s Interoperability Focus

JSON deliberately employs a “lowest common denominator” information model.[9] It supports only six basic, universal data types: object, array, string, number, boolean, and null.[1]

This design choice maximizes interoperability across diverse programming environments. By limiting the scope of types, JSON ensures that data serialized in one modern programming language can be trivially and reliably deserialized into the native data structures of any other language without requiring complex custom type mapping or specialized processing.[9]

4.2 YAML’s Native Data Flexibility and Type Tagging

In contrast to JSON, YAML’s design supports richer native data types corresponding to the semantics of dynamic programming languages.[1] It handles sequences (lists), scalars (numbers, strings, dates), and mappings (key-value pairs) with greater flexibility.

Anchors and Aliases: A major functional distinction is YAML’s support for defining reusable data blocks through anchors (&) and referencing them via aliases (*).[5] This feature provides two distinct advantages:

Reduced Redundancy: In configuration files, large, repeated blocks of settings can be defined once, improving file maintainability (DRY principle).
Complex Graph Serialization: This relational mechanism enables YAML to serialize data structures with internal relationships, such as complex object graphs, unlike JSON, which inherently requires full duplication of related data objects.[7]

4.3 XML Schema Definition (XSD): Granular Control and Namespaces

XML provides the most powerful and demanding mechanisms for ensuring data integrity through the use of XSD.

Strict Contracts and Custom Types: XSD allows for the definition of custom data types far beyond JSON’s primitives, including specific date and time formats, enumerated types, images, and complex numerical structures.[6] This rigorous type enforcement is fundamental in regulated or high-stakes environments where data consistency is non-negotiable.[16] The validation against XSD enforces a strict contract, ensuring that the XML document conforms precisely to predefined structural and type rules.

Modular Namespaces: Namespaces are crucial for architects managing large systems. By providing a mechanism to logically partition and qualify element and attribute names, namespaces enable schemas to be broken down into multiple reusable files.[18] This modularity simplifies development, reduces the potential for naming collisions when integrating multiple schema components, and facilitates version control and maintenance.[18]

4.4 Debugging and Error Handling Challenges

Error handling differs greatly based on the format’s structural reliance.

YAML Indentation Sensitivity: YAML’s reliance on indentation for defining structure, while enhancing readability, is a significant source of developer error and debugging challenge.[3] Inconsistent indentation (e.g., using tabs instead of spaces, or mixing indentation levels) often leads to cryptic parsing errors that are notoriously difficult to trace.[20] Given this fragility, architects must mandate the use of YAML validators and linters within CI/CD pipelines to catch these common, frustrating errors before deployment.[20]

XML Validation and Namespace Conflicts: Debugging XML typically centers on validation failures. The most common issues involve mismatched data types, the omission of required elements defined in the XSD, or, in complex enterprise environments, the incorrect application or resolution of namespaces.[16] XML parsers utilizing XSD (e.g., via XmlSchemaSet in.NET) raise specific validation events (warnings or errors) that developers must explicitly handle to troubleshoot schema non-conformance.[21]

V. Architectural Decision Framework: Defining Modern Use Cases

The selection among JSON, XML, and YAML should be driven by the primary architectural requirement: speed, human maintainability, or structural integrity.

5.1 JSON: The Dominant Data Exchange Layer

JSON is the definitive, default choice for modern machine-to-machine data exchange.[8]

Use Case: RESTful APIs, Microservice Communication, Message Queues (e.g., Kafka, RabbitMQ), Client-Side Data State, Configuration for Automated Systems.

Rationale: JSON’s core strength lies in its unmatched speed and minimal bandwidth consumption.[4] Its universal grammar ensures that processing overhead is minimized, making it suitable for low-latency, real-time data pipelines. Furthermore, its native integration into JavaScript environments ensures seamless operation across client-side applications and web services, cementing its ubiquity in the internet infrastructure.[2] The performance gains derived from libraries like simdjson solidify JSON’s position for scenarios where throughput is the paramount concern.

5.2 YAML: Configuration Management and Human-Readable State

YAML is the preferred format for scenarios where human operators frequently interact with and modify the structured data.

Use Case: DevOps Tooling (Kubernetes manifests, Ansible playbooks), Application Configuration Files, Infrastructure as Code (IaC) definitions.

Rationale: The superior human readability afforded by indentation-based structure, coupled with support for essential documentation via comments, dramatically enhances human operational efficiency.[2] For complex deployments (e.g., cloud infrastructure defined by YAML), the use of anchors and aliases allows engineers to create non-redundant, highly maintainable configurations, minimizing boilerplate and ensuring consistency across definition blocks.[19] While YAML parsing is slower than JSON, this performance penalty is entirely acceptable in configuration loading scenarios, which occur infrequently compared to high-volume API transaction processing.[22]

5.3 XML: Enterprise Legacy and Strict Document Modeling

XML maintains relevance in specific, highly specialized domains where data fidelity and complex document structuring are mandatory requirements.

Use Case: Inter-Enterprise Data Exchange, Systems Requiring Digital Signatures (e.g., SAML, WS-Security), Highly Regulated Document Workflows (e.g., HL7 for healthcare, XBRL for financial reporting).

Rationale: XML’s primary advantage lies in its unmatched ability to enforce strict contracts via XSD.[8] When structural integrity and verifiable conformance to an external, established schema are required, the overhead of XML parsing is justified. The availability of features like namespaces for modularity and the native support for attributes allow for semantic richness necessary in complex document models.[8] In sectors like finance and healthcare, where data compliance outweighs raw performance, XML remains the standard.

VI. Code Examples: Side-by-Side Data Structure

To illustrate the syntactic differences and structural overhead, the following example represents a product record for a software application.

6.1 Sample Data Structure: Product Record

The data structure represents a single product with an identifier, name, price, an array of available sizes, and an array of customer review objects.

6.2 JSON Implementation (Compactness and Delimiters)

{
  "product_id": "P_4567",
  "name": "Tech Comparison Guide",
  "price": 49.99,
  "in_stock": true,
  "sizes_available": ["A4", "Letter", "Digital"],
  "reviews": [
    {
      "user": "SeniorDev1",
      "rating": 5,
      "date": "2025-01-15T10:00:00Z"
    },
    {
      "user": "Architect2",
      "rating": 4,
      "date": "2025-01-16T11:30:00Z"
    }
  ]
}

6.3 YAML Implementation (Clarity and Indentation)

product_id: P_4567
name: Tech Comparison Guide
price: 49.99
in_stock: True
# Using hyphens and indentation for lists and objects
sizes_available:
  - A4
  - Letter
  - Digital

reviews:
  - user: SeniorDev1
    rating: 5
    date: 2025-01-15T10:00:00Z
  - user: Architect2
    rating: 4
    date: 2025-01-16T11:30:00Z

6.4 XML Implementation (Verbose and Tag-Heavy)

<product xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <product_id>P_4567</product_id>
    <name>Tech Comparison Guide</name>
    <price currency="USD">49.99</price>
    <in_stock>true</in_stock>
    <sizes_available>
        <size>A4</size>
        <size>Letter</size>
        <size>Digital</size>
    </sizes_available>
    <reviews>
        <review>
            <user>SeniorDev1</user>
            <rating>5</rating>
            <date>2025-01-15T10:00:00Z</date>
        </review>
        <review>
            <user>Architect2</user>
            <rating>4</rating>
            <date>2025-01-16T11:30:00Z</date>
        </review>
    </reviews>
</product>

The comparison clearly demonstrates the syntactic overhead: XML requires 11 lines of tags just to define the two review objects, whereas YAML achieves the same structure with minimal characters, and JSON relies on explicit delimiters for boundaries.

VII. Conclusion: Strategic Recommendations for 2025

For senior developers and architects, the decision regarding serialization format is a functional trade-off between performance, structural richness, and human interaction requirements. In 2025, JSON remains the undeniable standard for speed and integration, YAML dominates maintainable configuration, and XML retains its niche for high-integrity document modeling.

7.1 Strategic Recommendation Summary

The following framework summarizes the optimal format based on primary architectural driver:

Scenario	Format	Primary Rationale
High-Speed API/Data Transfer	JSON	Maximum throughput, minimal latency, lowest overhead, and universal machine support.
Configuration & Human Maintainability	YAML	Superior human readability, support for comments, and robust structure management via anchors.
Rigid Validation & Metadata Requirements	XML	Unmatched data integrity via XSD, strict type checking, and namespace modularity.

7.2 The Future of Serialization: Beyond the Text Formats

While JSON, XML, and YAML address human and machine readability in the text domain, modern systems targeting extreme performance often look beyond text formats entirely. Binary serialization formats, such as Protocol Buffers, Apache Thrift, and Apache Avro, offer further significant advantages in speed and file size optimization compared to JSON.[23] These formats prioritize machine efficiency and data schema definition, sacrificing human readability entirely.

For architects designing ultra-high-throughput systems where data volume and speed are more critical than inspection, the future may involve shifting core data exchange layers away from text-based formats and toward these dense, efficient binary alternatives. JSON will continue to serve as the necessary interface layer between these optimized cores and external services or human-facing applications.

Sources

YAML vs JSON - Difference Between Data Serialization Formats - AWS, accessed: november 23, 2025, https://aws.amazon.com/compare/the-difference-between-yaml-and-json/
JSON vs YAML: Comparing Data Formats for Modern Development - Latenode, accessed: november 23, 2025, https://latenode.com/blog/development-programming/code-examples-snippets/json-vs-yaml
JSON, YAML, TOML, or XML? The Best Choice for 2025 - Leapcell, accessed: november 23, 2025, https://leapcell.io/blog/json-yaml-toml-xml-best-choice-2025
JSON vs XML: which one is faster and more efficient? - Imaginary Cloud, accessed: november 23, 2025, https://www.imaginarycloud.com/blog/json-vs-xml
JSON vs YAML vs TOML vs XML: Best Data Format in 2025 - DEV Community, accessed: november 23, 2025, https://dev.to/leapcell/json-vs-yaml-vs-toml-vs-xml-best-data-format-in-2025-5444
JSON vs XML - Difference Between Data Representations - AWS, accessed: november 23, 2025, https://aws.amazon.com/compare/the-difference-between-json-xml/
What is the difference between YAML and JSON? - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/1726802/what-is-the-difference-between-yaml-and-json
YAML JSON and XML A Practical Guide to Choosing the Right Format - CelerData, accessed: november 23, 2025, https://celerdata.com/glossary/yaml-json-and-xml-a-practical-guide-to-choosing-the-right-format
How is it that json serialization is so much faster than yaml serialization in Python?, accessed: november 23, 2025, https://stackoverflow.com/questions/2451732/how-is-it-that-json-serialization-is-so-much-faster-than-yaml-serialization-in-p
simdjson/simdjson: Parsing gigabytes of JSON per second : used by Facebook/Meta Velox, the Node.js runtime, ClickHouse, WatermelonDB, Apache Doris, Milvus, StarRocks - GitHub, accessed: november 23, 2025, https://github.com/simdjson/simdjson
Benchmarking Gob vs JSON, XML & YAML | by Roman Sheremeta - Medium, accessed: november 23, 2025, https://rsheremeta.medium.com/benchmarking-gob-vs-json-xml-yaml-48b090b097e8
What is the difference between SAX and DOM? - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/6828703/what-is-the-difference-between-sax-and-dom
How does the data structure for a lexical analysis look? - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/43065653/how-does-the-data-structure-for-a-lexical-analysis-look
Writing a simple JSON parser | notes.eatonphil.com, accessed: november 23, 2025, https://notes.eatonphil.com/writing-a-simple-json-parser.html
JSON Schema vs XML Schema - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/26233414/json-schema-vs-xml-schema
Troubleshoot XML Schema Errors with Quick Fix Solutions - MoldStud, accessed: november 23, 2025, https://moldstud.com/articles/p-troubleshoot-xml-schema-errors-with-quick-fix-solutions
XML Schema: Understanding Namespaces - Oracle, accessed: november 23, 2025, https://www.oracle.com/technical-resources/articles/srivastava-namespaces.html
XML Schema Tutorial - Namespaces - Liquid Technologies, accessed: november 23, 2025, https://www.liquid-technologies.com/xml-schema-tutorial/xsd-namespaces
Why did YAML become the preferred configuration format instead of JSON? - Reddit, accessed: november 23, 2025, https://www.reddit.com/r/learnprogramming/comments/1m9yyba/why_did_yaml_become_the_preferred_configuration/
How can I debug issues with YAML files that are causing errors in my application?, accessed: november 23, 2025, https://moldstud.com/articles/p-how-can-i-debug-issues-with-yaml-files-that-are-causing-errors-in-my-application
XML Schema (XSD) Validation with XmlSchemaSet - .NET - Microsoft Learn, accessed: november 23, 2025, https://learn.microsoft.com/en-us/dotnet/standard/data/xml/xml-schema-xsd-validation-with-xmlschemaset
JSON vs YAML vs XML — when to use what? | by Kasturi Kugathas | Black Book for Data, accessed: november 23, 2025, https://medium.com/black-book-for-data/json-vs-yaml-vs-xml-when-to-use-what-1994d4448335
Comparing Data Serialization Formats: Code, Size, and Performance - Qt, accessed: november 23, 2025, https://www.qt.io/blog/comparing-data-serialization-formats
Comparison of data-serialization formats - Wikipedia, accessed: november 23, 2025, https://en.wikipedia.org/wiki/Comparison_of_data-serialization_formats