XML vs JSON: khác biệt và khi nào dùng cái nào

19/07/2026

Khi hai hệ thống cần "nói chuyện" với nhau — trình duyệt gọi API, service này gửi dữ liệu cho service kia, hay ứng dụng đọc file cấu hình — chúng cần một định dạng trao đổi dữ liệu chung mà cả bên gửi lẫn bên nhận đều hiểu. Suốt hơn hai thập kỷ qua, hai cái tên thống trị mảng này là XML (eXtensible Markup Language) và JSON (JavaScript Object Notation). Cả hai đều là text thuần, đọc được bằng mắt người và parse được bằng máy, độc lập với ngôn ngữ lập trình. Nhưng chúng ra đời với triết lý khác nhau, và việc chọn đúng định dạng có thể tiết kiệm cho bạn rất nhiều công sức. Bài viết này so sánh chi tiết hai định dạng và giúp bạn quyết định khi nào dùng cái nào.

XML là gì?

XML xuất hiện cuối thập niên 1990, được thiết kế như một ngôn ngữ đánh dấu (markup) tổng quát để mô tả dữ liệu có cấu trúc. Nó là "họ hàng" của HTML: dữ liệu được bao bọc trong các thẻ (tag) mở và đóng, các phần tử có thể lồng nhau (nested), và mỗi phần tử có thể mang thêm thuộc tính (attribute).

Một tài liệu XML thường bắt đầu bằng dòng khai báo <?xml ... ?> cho biết phiên bản và bảng mã. Ví dụ, mô tả một danh sách nhân viên:

<?xml version="1.0" encoding="UTF-8"?>
<company name="GemCorp">
  <!-- Danh sách nhân viên phòng kỹ thuật -->
  <employee id="1" active="true">
    <name>Nguyễn Văn A</name>
    <age>29</age>
    <skills>
      <skill>Java</skill>
      <skill>PostgreSQL</skill>
    </skills>
  </employee>
  <employee id="2" active="false">
    <name>Trần Thị B</name>
    <age>34</age>
    <skills>
      <skill>Docker</skill>
    </skills>
  </employee>
</company>

Ở đây <company> là phần tử gốc, name="GemCorp" là một thuộc tính, còn id và active là thuộc tính của từng <employee>. Dòng bắt đầu bằng  là một comment — XML cho phép chú thích ngay trong tài liệu.

Cùng dữ liệu đó viết bằng JSON

JSON ra đời đầu những năm 2000, tách ra từ cú pháp object literal của JavaScript. Thay vì thẻ, JSON dùng cặp key–value, object bọc trong { } và mảng bọc trong [ ]. Cùng dữ liệu nhân viên ở trên:

{
  "company": "GemCorp",
  "employees": [
    {
      "id": 1,
      "active": true,
      "name": "Nguyễn Văn A",
      "age": 29,
      "skills": ["Java", "PostgreSQL"]
    },
    {
      "id": 2,
      "active": false,
      "name": "Trần Thị B",
      "age": 34,
      "skills": ["Docker"]
    }
  ]
}

Nhìn thoáng qua đã thấy JSON ngắn hơn đáng kể: không có thẻ đóng lặp lại, không có dòng khai báo, và mảng skills gọn hơn nhiều so với việc lặp <skill> trong XML.

So sánh chi tiết

Độ dài và khả năng đọc

XML verbose hơn hẳn vì mỗi phần tử phải có thẻ đóng tương ứng (<name>...</name>). Với dữ liệu lớn, phần "boilerplate" này làm file phình to và tốn băng thông. JSON gọn, ít ký tự thừa, nên hầu hết REST API ngày nay chọn JSON để giảm payload. Bù lại, thẻ tên rõ ràng của XML đôi khi giúp người đọc hiểu ngữ cảnh nhanh hơn khi cấu trúc phức tạp.

Hỗ trợ kiểu dữ liệu

Đây là khác biệt cốt lõi. JSON có sẵn các kiểu dữ liệu: chuỗi, số, boolean (true/false), null, mảng và object. Trong ví dụ trên, 29 là số và true là boolean — parser tự hiểu. XML thì mọi thứ đều là text: <age>29</age> trả về chuỗi "29", ứng dụng phải tự ép kiểu, hoặc dựa vào schema (XSD) để biết đó là số.

Comment và attribute

Comment: XML hỗ trợ chú thích bằng . JSON không có comment trong đặc tả chính thức — đây là điểm hay bị phàn nàn khi dùng JSON làm file cấu hình (nhiều biến thể như JSON5, JSONC ra đời để bù đắp).
Attribute: XML tách bạch giữa thuộc tính (metadata gắn trên thẻ, như id="1") và nội dung phần tử. JSON chỉ có key–value phẳng — không có khái niệm attribute, nên khi chuyển XML sang JSON người ta thường phải quy ước (ví dụ dùng key "@id").

Namespace, schema và validation

XML hỗ trợ namespace (tránh trùng tên thẻ khi trộn nhiều vocabulary) và có hệ thống schema trưởng thành: XSD (XML Schema Definition) và DTD cho phép định nghĩa cấu trúc, kiểu, ràng buộc rất chặt chẽ — rồi validate tài liệu theo đó. JSON có JSON Schema làm nhiệm vụ tương tự, ngày càng phổ biến, nhưng ra đời sau và nhìn chung ít "nặng đô" hơn XSD. Với các hệ thống doanh nghiệp cần hợp đồng dữ liệu nghiêm ngặt, hệ sinh thái schema của XML vẫn là điểm mạnh.

Transform và truy vấn

XML có bộ công cụ mạnh để biến đổi và truy vấn: XSLT chuyển đổi một tài liệu XML sang định dạng khác (XML, HTML, text), còn XPath cho phép trỏ tới bất kỳ node nào bằng cú pháp giống đường dẫn. JSON không có chuẩn transform chính thức tương đương; giới lập trình thường xử lý bằng code (JavaScript, jq, hoặc JSONPath cho truy vấn). Nếu công việc của bạn xoay quanh việc "nhào nặn" tài liệu, XSLT/XPath vẫn rất đáng giá.

Bảng tổng hợp

Tiêu chí	XML	JSON
Độ dài / verbose	Dài, nhiều boilerplate	Gọn, ít ký tự thừa
Khả năng đọc	Rõ ngữ cảnh nhưng rối khi lớn	Dễ đọc, trực quan
Kiểu dữ liệu	Chỉ text (cần ép kiểu)	Có số, boolean, null, mảng
Comment	Có (`<!-- -->`)	Không (chuẩn gốc)
Attribute	Có (metadata trên thẻ)	Không, chỉ key–value
Namespace	Có	Không
Schema	XSD, DTD (rất mạnh)	JSON Schema
Transform / truy vấn	XSLT, XPath	Xử lý bằng code, JSONPath
Ứng dụng điển hình	SOAP, cấu hình enterprise, tài liệu	REST API, web, mobile

Khi nào XML vẫn hợp lý?

SOAP web service: giao thức SOAP bắt buộc dùng XML, phổ biến trong ngân hàng, viễn thông, hệ thống liên ngân hàng.
Cấu hình doanh nghiệp cũ: nhiều framework Java/.NET đời trước (Spring XML config, Maven pom.xml, web.xml) dựa trên XML.
Tài liệu có cấu trúc phức tạp, trộn văn bản và markup: ví dụ DOCX, SVG, RSS — nơi nội dung là văn bản dài xen thẻ định dạng, mô hình markup của XML tự nhiên hơn.
Cần validation và transform mạnh: khi hợp đồng dữ liệu phải khóa chặt bằng XSD, hoặc cần chuyển đổi tài liệu bằng XSLT.

Khi nào JSON tốt hơn?

REST API: mặc định của web hiện đại, payload nhẹ, dễ debug.
Ứng dụng web và mobile: JSON là JavaScript-native — JSON.parse()/JSON.stringify() có sẵn, không cần thư viện.
File cấu hình nhẹ: package.json, tsconfig.json... tuy nhược điểm là thiếu comment.
Giao tiếp giữa microservice: tốc độ parse nhanh, kích thước nhỏ giúp giảm độ trễ.

Đừng quên format khi debug

Dù chọn định dạng nào, khi debug hãy luôn format/indent tài liệu cho dễ đọc. Dữ liệu truyền qua mạng thường bị "minify" thành một dòng dài để tiết kiệm băng thông — nhìn vào đó rất khó soi lỗi. XML đặc biệt dễ rối nếu không format, vì thẻ đóng/mở đan xen nhau; một tài liệu XML lồng sâu mà nằm trên một dòng gần như không thể đọc bằng mắt. Bạn có thể dán tài liệu vào XML Formatter để tự động thụt lề và tô màu cú pháp, hoặc dùng JSON Formatter cho dữ liệu JSON — cả hai đều chạy hoàn toàn trong trình duyệt, không gửi dữ liệu của bạn lên server.

Kết luận

Không có định dạng "thắng tuyệt đối" — chúng phục vụ những nhu cầu khác nhau. JSON gọn nhẹ, có kiểu dữ liệu sẵn, native với JavaScript, nên là lựa chọn mặc định cho REST API, web và mobile ngày nay. XML verbose hơn nhưng bù lại có comment, attribute, namespace và bộ công cụ schema/transform (XSD, XSLT, XPath) trưởng thành — vẫn không thể thay thế trong SOAP, cấu hình enterprise cũ và tài liệu có cấu trúc phức tạp. Quy tắc thực dụng: API mới thì chọn JSON; khi buộc phải làm việc với hệ thống XML sẵn có, hãy dùng đúng thế mạnh của nó.

Đang phải soi một đống XML rối tung? Dán nó vào XML Formatter của DevToolHub để format, thụt lề và tô màu cú pháp ngay trong trình duyệt — nhanh, riêng tư và miễn phí.