JSON vs XML vs YAML: Perbedaan dan Kapan Memakainya

JSON, XML, dan YAML sama-sama format teks untuk data terstruktur, tetapi kekuatannya berbeda: JSON paling cocok untuk API dan pertukaran data antar program, YAML paling nyaman untuk file konfigurasi yang ditulis manusia, sedangkan XML unggul untuk dokumen yang butuh atribut, namespace, dan validasi skema ketat. Jika Anda ragu, aturan praktisnya: API pakai JSON, konfigurasi pakai YAML (atau JSON), dan pakai XML bila ekosistem atau standar yang Anda hadapi memang mewajibkannya. Artikel ini membandingkan ketiganya secara rinci, lengkap dengan jebakan indentasi YAML dan cara mengonversi di antara ketiganya.

Contoh data yang sama dalam tiga format

Cara tercepat memahami perbedaan adalah melihat satu data yang sama ditulis tiga kali. Misalnya data sebuah server aplikasi.

JSON:

{
  "nama": "api-produksi",
  "port": 8080,
  "debug": false,
  "domain": ["api.contoh.com", "www.contoh.com"],
  "database": {
    "host": "127.0.0.1",
    "user": "app"
  }
}

YAML:

# Konfigurasi server produksi
nama: api-produksi
port: 8080
debug: false
domain:
  - api.contoh.com
  - www.contoh.com
database:
  host: 127.0.0.1
  user: app

XML:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Konfigurasi server produksi -->
<server nama="api-produksi">
  <port>8080</port>
  <debug>false</debug>
  <domain>api.contoh.com</domain>
  <domain>www.contoh.com</domain>
  <database host="127.0.0.1" user="app"/>
</server>

Terlihat jelas: YAML paling ringkas dan mendukung komentar, JSON paling eksplisit dengan kurung dan kutip, sedangkan XML paling panjang tetapi punya konsep atribut (nama="api-produksi") yang tidak dimiliki dua format lainnya. Perhatikan juga bahwa di XML semua nilai pada dasarnya teks; 8080 dan false baru punya tipe bila skema atau kode Anda menafsirkannya.

Tabel perbandingan JSON vs XML vs YAML

JSON: pilihan default untuk API

JSON menjadi standar de facto untuk API karena tiga hal: parser-nya tersedia di semua bahasa, sintaksnya kecil sehingga perilakunya konsisten antar implementasi, dan tipe datanya langsung terpetakan ke struktur bahasa pemrograman (objek, array, angka). Di browser, JSON.parse dan fetch().json() sudah tersedia tanpa library tambahan. Jika Anda ingin memahami bagaimana JSON berperan dalam request dan response, baca apa itu REST API dan cara kerjanya.

Kelemahan JSON terasa saat dipakai sebagai file konfigurasi yang diedit manusia: tidak ada komentar, trailing comma membuat error, dan banyak tanda kutip. Itulah alasan sebagian proyek beralih ke JSONC, JSON5, YAML, atau TOML untuk konfigurasi. Untuk memeriksa struktur JSON yang panjang, Anda bisa memakai JSON Viewer.

XML: kuat untuk dokumen dan standar formal

XML sering dianggap kuno, padahal masih dipakai luas di tempat yang membutuhkan fiturnya. Kelebihan XML:

• Atribut dan konten campuran. XML bisa memuat teks bercampur elemen, seperti <p>Halo <b>dunia</b></p>. Inilah alasan XML cocok untuk dokumen, sedangkan JSON tidak.
• Namespace. Beberapa kosakata bisa digabung dalam satu dokumen tanpa bentrok nama, misalnya sitemap dengan ekstensi gambar.
• Skema yang matang. XSD memungkinkan validasi tipe, urutan elemen, dan kardinalitas dengan ketat, yang penting di integrasi perbankan, pemerintahan, atau sistem perusahaan.
• Ekosistem pemrosesan. XPath untuk mencari node, XSLT untuk transformasi.

Anda akan bertemu XML pada sitemap.xml untuk SEO, feed RSS/Atom, file SVG, layanan SOAP, file .docx/.xlsx (yang sebenarnya arsip ZIP berisi XML), serta konfigurasi seperti phpunit.xml di proyek Laravel.

Satu catatan keamanan: parser XML yang memproses entitas eksternal rentan terhadap serangan XXE (XML External Entity). Di PHP 8 dengan libxml modern, pemuatan entitas eksternal nonaktif secara default, jadi jangan menyalakannya (misalnya lewat flag LIBXML_NOENT) ketika memproses XML dari sumber yang tidak tepercaya.

YAML: nyaman untuk konfigurasi, tapi penuh jebakan

YAML dirancang agar mudah dibaca dan ditulis manusia. Struktur ditentukan oleh indentasi, list ditandai tanda hubung, dan komentar memakai #. Karena itulah YAML menjadi format utama Docker Compose, Kubernetes, GitHub Actions, GitLab CI, Ansible, dan spesifikasi OpenAPI. YAML 1.2 juga dirancang agar hampir semua dokumen JSON sekaligus merupakan YAML yang valid.

Namun kemudahan itu dibayar dengan aturan implisit yang sering menjebak.

Jebakan 1: tab tidak boleh untuk indentasi

Spesifikasi YAML melarang karakter tab untuk indentasi. Editor yang diam-diam memasukkan tab akan membuat parser gagal dengan pesan seperti found character that cannot start any token (redaksi bergantung pada library). Atur editor Anda agar memakai spasi untuk file .yml dan .yaml.

Jebakan 2: indentasi yang tidak konsisten mengubah makna

# Maksudnya: environment milik service "web"
services:
  web:
    image: nginx
  environment:      # salah: sejajar dengan "web", jadi dianggap service baru
    - APP_ENV=production

Di sini environment terbaca sebagai service bernama "environment", bukan pengaturan milik web. Parser tidak selalu error; kadang hasilnya valid tetapi maknanya salah. Inilah yang membuat bug YAML sulit dilacak.

Jebakan 3: tipe data yang ditebak otomatis

YAML menebak tipe dari bentuk nilai tanpa kutip. Akibatnya:

• versi: 1.10 menjadi angka 1.1, bukan string "1.10".
• Di parser yang mengikuti YAML 1.1, negara: NO bisa terbaca sebagai boolean false (dikenal sebagai "Norway problem"), begitu juga yes, no, on, off.
• Angka berawalan nol seperti izin: 0755 bisa ditafsirkan sebagai oktal oleh sebagian parser.
• Kode pos atau nomor telepon berawalan nol bisa kehilangan nol di depannya.

Solusinya sederhana: beri kutip pada nilai yang harus tetap string, misalnya versi: "1.10" dan negara: "NO".

Jebakan 4: memuat YAML dari sumber tak tepercaya

Beberapa library YAML mendukung tag yang bisa membuat objek arbitrer. Di Python, misalnya, gunakan yaml.safe_load(), bukan yaml.load() tanpa loader aman, saat membaca input dari luar.

Kapan memakai yang mana

• Membangun REST API atau komunikasi frontend-backend: JSON. Didukung native oleh browser dan semua framework.
• File konfigurasi yang sering diedit manusia: YAML, karena ringkas dan mendukung komentar. Jika tim sering salah indentasi, JSON atau TOML bisa lebih aman.
• Dokumen dengan teks campuran, atribut, atau standar industri: XML. Contohnya sitemap, RSS, SVG, dan integrasi SOAP.
• Data yang dikonsumsi mesin dalam volume besar: JSON, atau format biner seperti Protocol Buffers bila performa sangat penting.
• Mengikuti ekosistem: jika alatnya meminta format tertentu (Kubernetes meminta YAML, sitemap meminta XML), ikuti saja.

Cara mengonversi antar format

Untuk konversi sekali jalan, cara termudah adalah memakai konverter JSON↔CSV/YAML: tempel data, pilih format tujuan, dan salin hasilnya. Untuk otomatisasi di kode, berikut beberapa contoh.

JSON ke YAML dan sebaliknya di PHP

Gunakan paket symfony/yaml:

composer require symfony/yaml

use Symfony\Component\Yaml\Yaml;

// JSON -> YAML
$data = json_decode($json, true, 512, JSON_THROW_ON_ERROR);
$yaml = Yaml::dump($data, 4, 2); // level inline 4, indentasi 2 spasi

// YAML -> JSON
$data = Yaml::parse($yaml);
$json = json_encode($data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES);

XML ke JSON di PHP

$xml  = simplexml_load_string($teksXml);
$json = json_encode($xml, JSON_PRETTY_PRINT);
$data = json_decode($json, true);

Trik ini cepat tetapi tidak sempurna: atribut masuk ke kunci @attributes, elemen tunggal dan elemen berulang menghasilkan bentuk berbeda (objek vs array), dan teks campuran bisa hilang. Untuk XML yang kompleks, lebih baik membaca node secara eksplisit dengan SimpleXML atau DOM.

Di terminal

# YAML -> JSON dengan yq (versi Go oleh Mike Farah)
yq -o=json config.yaml

# JSON -> YAML
yq -p=json -o=yaml data.json

Apa yang hilang saat konversi

• Komentar hilang ketika YAML atau XML diubah ke JSON.
• Atribut XML tidak punya padanan langsung di JSON/YAML, sehingga perlu konvensi seperti @attributes atau awalan @.
• Tipe data dari XML (semua teks) harus ditafsirkan ulang secara manual.
• Anchor dan alias YAML (& dan *) akan diekspansi menjadi data berulang di JSON.

Kesalahan umum

• Memilih XML untuk API baru tanpa alasan kuat, sehingga klien harus menulis parser yang lebih rumit.
• Menulis YAML tanpa linter, lalu baru tahu salah indentasi ketika deploy gagal. Gunakan yamllint atau validasi di CI.
• Tidak memberi kutip pada versi, kode negara, atau angka berawalan nol di YAML.
• Mengandalkan konversi otomatis XML ke JSON untuk data penting tanpa memeriksa bentuk hasilnya.

Ringkasan

• JSON: ketat, ringkas, didukung di mana-mana, ideal untuk API.
• XML: verbose tetapi kaya fitur (atribut, namespace, XSD), ideal untuk dokumen dan standar formal.
• YAML: paling enak dibaca, mendukung komentar, ideal untuk konfigurasi, tapi rawan salah indentasi dan salah tebak tipe.
• Konversi antar format hampir selalu kehilangan sesuatu: komentar, atribut, atau informasi tipe.

FAQ

Apakah YAML lebih baik dari JSON?

Tidak secara mutlak. YAML lebih nyaman untuk konfigurasi yang ditulis manusia, sedangkan JSON lebih aman dan cepat untuk data yang dipertukarkan antar program. Pilih sesuai siapa yang paling sering membaca dan menulis file tersebut.

Apakah XML masih relevan?

Ya. Sitemap, RSS, SVG, file Office, dan banyak integrasi perusahaan maupun pemerintahan masih memakai XML. Untuk API baru, JSON umumnya lebih praktis.

Apakah file JSON bisa langsung dibaca sebagai YAML?

Pada parser YAML 1.2, hampir semua dokumen JSON adalah YAML yang valid. Namun ada kasus tepi, dan parser YAML 1.1 bisa berperilaku sedikit berbeda, jadi uji dulu sebelum mengandalkannya.

Kenapa file YAML saya error padahal terlihat rapi?

Penyebab tersering adalah karakter tab yang tidak terlihat atau jumlah spasi yang tidak konsisten. Aktifkan tampilan whitespace di editor dan jalankan linter YAML.

Format mana yang paling hemat ukuran?

YAML dan JSON minified sama-sama ringkas, sedangkan XML paling besar karena tag penutup. Untuk transfer lewat jaringan, JSON dengan kompresi gzip atau brotli biasanya sudah sangat efisien.