JSON vs XML: Which Data Format Should You Use?

XML dominated data interchange for over a decade. Then JSON showed up and changed everything. Here's why — and when XML is still the better choice.

Команда JSONTechFebruary 20, 202510 min read

Быстрый урок истории

XML (расширяемый язык разметки) появился в 1998 году, когда Java-апплеты и SOAP веб-сервисы были передовыми технологиями. Он был разработан как упрощённый подмножество SGML — метаязыка, лежащего в основе HTML — и справлялся со своей задачей хорошо. На протяжении многих лет XML был стандартом для обмена данными, конфигурации, хранения документов и, по сути, всего остального.

Затем, в начале 2000-х, веб-разработчики начали создавать AJAX-приложения и поняли, что им нужно что-то легче, чем XML, для передачи данных между браузерами и серверами. Дуглас Крокфорд формализовал JSON примерно в 2001-2002 годах, и переход был быстрым. К 2010 году большинство новых REST API использовали JSON. К 2015 году это уже не вызывало споров.

Но вот в чём ошибка людей: XML не "проиграл". Он отступил в области, где действительно преуспевает. Понимание этих областей отделяет продуманное архитектурное решение от слепого следования моде.

Сравнение синтаксиса

Давайте посмотрим на одни и те же данные — список книг — представленных в обоих форматах:

JSON

{
  "library": {
    "books": [
      {
        "isbn": "978-0-13-468599-1",
        "title": "The Pragmatic Programmer",
        "author": "David Thomas, Andrew Hunt",
        "year": 2019,
        "available": true,
        "tags": ["programming", "best-practices", "career"]
      },
      {
        "isbn": "978-0-596-51774-8",
        "title": "JavaScript: The Good Parts",
        "author": "Douglas Crockford",
        "year": 2008,
        "available": false,
        "tags": ["javascript", "programming"]
      }
    ]
  }
}

XML

<?xml version="1.0" encoding="UTF-8"?>
<library>
  <books>
    <book isbn="978-0-13-468599-1" available="true">
      <title>The Pragmatic Programmer</title>
      <author>David Thomas, Andrew Hunt</author>
      <year>2019</year>
      <tags>
        <tag>programming</tag>
        <tag>best-practices</tag>
        <tag>career</tag>
      </tags>
    </book>
    <book isbn="978-0-596-51774-8" available="false">
      <title>JavaScript: The Good Parts</title>
      <author>Douglas Crockford</author>
      <year>2008</year>
      <tags>
        <tag>javascript</tag>
        <tag>programming</tag>
      </tags>
    </book>
  </books>
</library>

Версия XML примерно на 40% больше, и это типично. Каждое имя элемента появляется дважды (открывающие и закрывающие теги), а массивы требуют обёрточных элементов. XML также имеет концепцию "атрибутов" против "элементов" — обратите внимание, как isbn и available являются атрибутами тега <book>, в то время как другие поля являются дочерними элементами. Эта гибкость является как преимуществом, так и источником бесконечных дебатов по дизайну.

JSON, в свою очередь, имеет один способ делать вещи: ключи и значения. Нет различия между атрибутами и элементами. Нет закрывающих тегов. Меньше церемоний, меньше неоднозначности.

Попробуйте сами: Вставьте JSON в наш конвертер JSON в XML, чтобы мгновенно увидеть эквивалент в XML. Или конвертируйте в другую сторону с помощью XML в JSON.

Сравнение функций

Функция	JSON	XML
Вербозность	Компактный	Многословный (открывающие + закрывающие теги)
Читаемость	Хорошо для структур данных	Хорошо для документов
Комментарии	❌ Нет	✅ Да (`<!-- комментарий -->`)
Проверка схемы	JSON Schema (отдельная спецификация)	XSD, DTD, RELAX NG (взрослые, мощные)
Поддержка пространств имен	❌ Нет	✅ Да (избегает конфликтов имен)
Типы данных	Строки, числа, булевы значения, null, объекты, массивы	Всё текст (типы только через схему)
Атрибуты	❌ Нет (только ключи)	✅ Да (метаданные на элементах)
Смешанное содержимое	❌ Нет	✅ Да (текст + разметка вперемешку)
Преобразование	Ручной код	XSLT (декларативные преобразования)
Язык запросов	JSONPath, JMESPath	XPath, XQuery (более зрелые)
Скорость парсинга	Быстро (простая грамматика)	Медленнее (сложная грамматика, валидация)
Встроенный парсинг в браузере	✅ `JSON.parse()`	✅ `DOMParser`
Размер файла (одни и те же данные)	Меньше (~60-70% от XML)	Больше (избыточные теги)
Экосистема инструментов	Современная, растущая	Зрелая, обширная

Когда XML всё ещё выигрывает

Я знаю, что соблазнительно полностью отказаться от XML. Сопротивляйтесь этому импульсу. Есть специфические области, где XML не просто адекватен, а действительно превосходит.

1. Разметка документов и смешанное содержимое

Это убийственная функция XML. Рассмотрим абзац с встроенным форматированием:

<paragraph>
  Это <bold>важный</bold> текст с
  <link href="/page">встроенной гиперссылкой</link>.
</paragraph>

Попробуйте представить это в JSON. Вы получите что-то ужасное — массив смешанных строк и объектов или какой-то синтаксис экранирования разметки. JSON был разработан для структурированных данных, а не для документов. XML был разработан для обоих.

Вот почему HTML (родственник XML), DocBook, DITA и форматы публикаций используют синтаксис на основе XML. EPUB-файлы — это XML. Файлы Microsoft Office (.docx, .xlsx) — это сжатый XML. Мир документов работает на XML, и JSON не собирается забирать этот трон.

2. SOAP веб-сервисы

Корпоративные системы, особенно в банковской сфере, здравоохранении и государственном управлении, по-прежнему сильно зависят от SOAP. Эти сервисы используют XML с строгими схемами (WSDL), и они не собираются переходить на REST в ближайшее время. Если вы интегрируетесь с устаревшими корпоративными API, вам придётся работать с XML, нравится вам это или нет.

3. Преобразования XSLT

XSLT позволяет вам декларативно преобразовывать XML-документы — перестраивать, фильтровать, форматировать — без написания процедурного кода. Это мощно для генерации HTML-отчетов из XML-данных, конвертации между XML-схемами и обработки документных конвейеров. У JSON нет эквивалента, который мог бы сравниться с возможностями XSLT.

4. Пространства имен

Когда вам нужно объединить данные из нескольких источников в одном документе без конфликтов имен, пространства имен XML решают эту задачу элегантно:

<root xmlns:hr="http://example.com/hr"
      xmlns:fin="http://example.com/finance">
  <hr:employee>
    <hr:name>Алиса</hr:name>
    <fin:salary currency="USD">95000</fin:salary>
  </hr:employee>
</root>

JSON не имеет концепции пространств имен. Если два API используют одно и то же имя ключа с разными значениями, вам придётся самостоятельно разрешать конфликт.

5. RSS, Atom и SVG

RSS и Atom ленты — это XML. Графика SVG — это XML. Эти форматы глубоко укоренены в веб-экосистеме и не собираются меняться. Если вы генерируете или потребляете что-либо из этого, вам нужна поддержка XML.

Когда JSON выигрывает

Для большинства современных задач разработки JSON является прагматичным выбором. Вот где он явно доминирует:

1. REST API

Цифры рассказывают историю. Согласно различным опросам API, более 90% публичных API используют JSON в качестве основного формата ответа. Он легче по объему, быстрее для парсинга и напрямую сопоставляется с нативными структурами данных в JavaScript, Python, Ruby, Go и большинстве других языков.

// Вызов REST API — ответ уже в формате JSON
const response = await fetch("https://api.github.com/users/octocat");
const user = await response.json();
console.log(user.login); // "octocat"

С XML вам нужно было бы создать парсер DOM, пройтись по узлам и вручную извлечь текстовое содержимое. С JSON вы просто вызываете .json() и получаете нативный объект. Разрыв в опыте разработчика огромен.

2. NoSQL базы данных

MongoDB, CouchDB, DynamoDB, Firestore, Elasticsearch — вся экосистема NoSQL построена вокруг JSON (или похожих на JSON) документов. Если ваши данные уже в формате JSON, хранение их в документной базе данных практически не требует усилий.

3. Мобильные и фронтенд-приложения

Мобильные приложения должны эффективно использовать пропускную способность и батарею. Меньший размер полезной нагрузки JSON и более быстрый парсинг напрямую влияют на производительность приложения. И iOS (Codable), и Android (Gson, Moshi, Kotlin Serialization) имеют отличные библиотеки для работы с JSON.

4. Конфигурация (с оговорками)

package.json, tsconfig.json, .eslintrc.json — JSON повсюду в экосистеме инструментов JavaScript. Отсутствие комментариев является настоящей болью здесь, поэтому многие инструменты теперь принимают JSONC или JSON5. Для более сложной конфигурации я рекомендую рассмотреть YAML как альтернативу.

5. Реальное время общения

Сообщения WebSocket, события, отправляемые сервером, и потоки данных в реальном времени почти универсально используют JSON. Компактность формата и нативный парсинг в браузере делают его идеальным для высокочастотного обмена данными.

Работаете с обоими форматами? Наши конвертеры JSON в XML и XML в JSON упрощают перевод между ними. Попробуйте вставить ваши данные и мгновенно увидеть результат.

Сдвиг в индустрии по цифрам

Сдвиг от XML к JSON был драматичным и хорошо задокументированным:

Тренды Stack Overflow: Вопросы с тегом "json" обогнали "xml" около 2013 года и теперь превышают их примерно в 2:1.
Форматы публичных API: Данные ProgrammableWeb показали, что JSON обошёл XML как наиболее предлагаемый формат API около 2011 года. Сегодня JSON доминирует с большим отрывом.
Экосистема npm: Главная библиотека для парсинга JSON (встроенная JSON.parse) не имеет зависимостей и поставляется с каждой средой выполнения JavaScript. Парсинг XML требует сторонних библиотек на большинстве языков.
Новые спецификации: Большинство новых стандартов данных (JSON-LD, GeoJSON, JSON Schema, JWT) основаны на JSON. Спецификации на основе XML в основном находятся в режиме обслуживания.

Тем не менее, такие отрасли, как здравоохранение (HL7, FHIR частично используют XML), издательское дело (EPUB, DITA), государственное управление (многие устаревшие системы) и финансы (протокол FIX, ISO 20022) по-прежнему сильно зависят от XML. Если вы работаете в этих секторах, знание XML не является опциональным.

Сравнение производительности

Для типичной полезной нагрузки данных вот как сравниваются два формата:

Метрика	JSON	XML
Время парсинга (1 МБ, Node.js)	~15ms	~60ms (SAX) / ~150ms (DOM)
Время сериализации	~10ms	~45ms
Размер полезной нагрузки (отформатированный)	1.0 МБ	1.5–1.7 МБ
Размер полезной нагрузки (минифицированный)	0.6 МБ	1.2 МБ (теги нельзя устранить)
Размер после сжатия	~120 КБ	~140 КБ (разница уменьшается при сжатии)

Сравнение после сжатия интересно — повторяющиеся теги XML действительно хорошо сжимаются, поэтому разница в размере значительно уменьшается после сжатия. Если вы отправляете сжатые ответы (что вы должны делать), аргумент о размере полезной нагрузки менее убедителен, чем кажется на первый взгляд. Однако разница в скорости парсинга остаётся значительной.

Советы по миграции

Если вы переходите с XML на JSON (распространённая задача), вот несколько моментов, на которые стоит обратить внимание:

Атрибуты не имеют прямого эквивалента. Атрибуты XML обычно становятся обычными свойствами JSON, иногда с префиксом @ от инструментов конверсии.
Смешанное содержимое трудно представить. Если ваш XML содержит текст, перемешанный с элементами, вам нужно будет решить, какую конвенцию использовать (например, массивы смешанных строк и объектов).
Информация о пространстве имен теряется. JSON не имеет концепции пространств имен, поэтому вам придётся вручную разрешать конфликты.
Порядок может иметь значение или нет. Порядок элементов XML имеет значение. Порядок ключей объектов JSON технически не гарантирован (хотя большинство реализаций сохраняют порядок вставки).
Проверяйте после конверсии. Используйте наш валидатор JSON, чтобы убедиться, что преобразованный вывод действителен, и инструмент JSON Compare, чтобы проверить целостность данных.

Вердикт

Для большинства современных веб-разработок JSON является правильным выбором по умолчанию. Он проще, легче, быстрее для парсинга и нативно поддерживается в браузерах. Моментум экосистемы подавляющий.

Но "используйте JSON для всего" — плохой совет. XML остаётся лучшим выбором для данных, ориентированных на документы, смешанного содержимого, сложной проверки схем, интеграций с большим количеством пространств имен и устаревших корпоративных систем. Знание обоих форматов — и когда каждый из них уместен — делает вас всесторонним разработчиком.

На моём опыте, лучший подход — прагматичный: используйте тот формат, который ожидает экосистема, в которой вы работаете, и не сопротивляйтесь течению. Конвертируйте между ними, когда это необходимо, и переходите к решению реальной проблемы.

Продолжайте исследовать:

Что такое JSON? — полное руководство для начинающих
JSON против YAML — ещё одно сравнение распространённых форматов
Конвертер JSON в XML
Конвертер XML в JSON
Форматировщик JSON — форматируйте и проверяйте JSON мгновенно