YAML Formatter

Format dan validasi YAML secara instan di browser Anda

YAML formatter ini memvalidasi dan merapikan YAML Anda secara real-time saat Anda mengetik atau menempel — tanpa perlu menekan tombol. Ini menormalkan indentasi, menyorot kesalahan sintaks dengan nomor baris dan penjelasan, dan menyediakan konversi sekali-klik ke JSON. Editor memiliki syntax highlighting penuh menggunakan properti kustom CSS yang beradaptasi dengan preferensi mode gelap atau terang sistem Anda. Semuanya berjalan di sisi klien menggunakan parser YAML JavaScript — file konfigurasi Anda tidak pernah meninggalkan perangkat Anda.

YAML (YAML Ain't Markup Language) digunakan di hampir setiap proyek perangkat lunak modern: workflow GitHub Actions, manifest Kubernetes, file Docker Compose, playbook Ansible, chart Helm, konfigurasi CI/CD, dan file konfigurasi aplikasi. Ini bisa dibaca manusia menurut desain, tetapi sensitivitas indentasi dan keanehan karakter khususnya membuatnya mengejutkan mudah menulis YAML yang tidak valid yang hanya gagal saat runtime — saat sudah terlambat. Formatter langsung menangkap kesalahan tersebut dalam hitungan detik.

Kesalahan YAML umum dan bagaimana validator menangkapnya

Kesalahan YAML paling umum adalah menggunakan tab alih-alih spasi. YAML melarang karakter tab dalam indentasi — mereka terlihat identik dengan spasi di sebagian besar editor teks tetapi menyebabkan kegagalan parsing segera. Validator menangkap ini dan memberi tahu Anda persis baris mana yang memiliki tab. Kesalahan kedua paling umum adalah titik dua yang tidak dikutip dalam nilai: `title: Hello: World` ambigu — parser melihat kunci bertingkat. Kutip nilainya: `title: "Hello: World"`. Ketiga adalah indentasi yang tidak konsisten: jika satu blok terindentasi 2 spasi di satu tempat dan 3 di tempat lain, parser mungkin salah membaca tingkat penyarangan.

Kesalahan umum lainnya: kunci duplikat dalam mapping yang sama (secara teknis diizinkan dalam YAML 1.1 tetapi ilegal dalam 1.2, dan ditolak oleh sebagian besar parser); spasi hilang setelah titik dua (`key:value` tidak valid, memerlukan `key: value`); anchor dan alias yang digunakan secara tidak benar; dan kejutan koersi tipe implisit (string `yes` menjadi boolean `true` dalam parser YAML 1.1). Validator melaporkan masing-masing dengan bahasa yang jelas, bukan hanya dump kesalahan parser mentah.

Konversi YAML ke JSON — kapan dan mengapa

JSON dan YAML adalah format data yang secara semantik setara (dengan beberapa pengecualian). YAML adalah superset dari JSON — JSON yang valid juga YAML yang valid. Mengonversi YAML ke JSON berguna saat bekerja dengan alat atau API yang hanya menerima JSON, atau saat Anda ingin menggunakan `jq` untuk mengkueri file konfigurasi YAML (jq beroperasi pada JSON). Tombol "Salin sebagai JSON" mengurai YAML Anda dan mengserialisasikannya menjadi JSON terformat dengan indentasi 2-spasi.

Satu catatan penting: komentar YAML (baris yang dimulai dengan `#`) tidak dipertahankan dalam output JSON karena JSON tidak memiliki sintaks komentar. Anchor dan alias YAML diresolusikan — JSON menampilkan nilai yang sudah didereferensikan akhir. YAML multi-dokumen (beberapa dokumen dipisahkan oleh `---`) dikonversi menjadi array JSON yang berisi setiap dokumen sebagai elemen. Jika Anda memerlukan kebalikannya (JSON ke YAML), tempel JSON ke formatter ini — karena JSON adalah YAML yang valid, ia akan mengurainya dan memformatnya ulang dengan bersih.

YAML formatter vs yamllint, YAML Lint, dan YAML Checker

yamllint adalah alat CLI standar emas untuk linting YAML — menyeluruh, dapat dikonfigurasi, dan digunakan dalam pipeline CI. Tetapi ini memerlukan Python, pip, dan terminal, membuatnya tidak dapat diakses untuk pemeriksaan cepat di mesin anggota tim atau di lingkungan browser. YAML Lint (yamllint.com) adalah alternatif online paling populer tetapi hanya menampilkan kesalahan — tanpa output terformat, tanpa konversi JSON. YAML Checker (yamlchecker.com) memformat dan memvalidasi tetapi memiliki editor teks polos tanpa highlighting dan tanpa output JSON. Transform.tools melakukan konversi YAML-ke-JSON tetapi tanpa validasi langsung.

Formatter ini menggabungkan semua kemampuan tersebut dalam satu tempat: validasi langsung dengan penjelasan kesalahan, output terformat dengan syntax highlighting, konversi JSON sekali-klik, dan dukungan multi-dokumen — berjalan sepenuhnya di browser Anda tanpa backend. Ini adalah jalur tercepat dari "apakah YAML ini valid?" ke "ini versi terformat, bebas-kesalahannya" bagi pengembang yang lebih suka tidak menginstal alat atau mendaftar layanan.

Penggunaan praktis — Kubernetes, GitHub Actions, Docker Compose

Untuk pengguna Kubernetes: tempel manifest Anda sebelum menerapkannya dengan `kubectl apply` untuk menangkap kesalahan sintaks lebih awal. Satu kesalahan indentasi dalam spec Pod atau definisi Service akan menyebabkan `kubectl` gagal dengan kesalahan yang kriptik; menangkapnya di sini terlebih dahulu menghemat waktu. Untuk pengguna GitHub Actions: tempel file `.github/workflows/*.yml` Anda untuk memvalidasi sebelum commit. Workflow yang malformed gagal secara diam-diam (aksi hanya tidak berjalan) dan men-debug-nya di UI GitHub lambat. Untuk pengguna Docker Compose: validasi `docker-compose.yml` Anda sebelum menjalankan `docker compose up` — sangat penting untuk file multi-layanan di mana kesalahan definisi layanan bertingkat bisa sulit dikenali.

Untuk pengguna Ansible: tempel playbook, file inventory, atau file variabel untuk memvalidasi struktur YAML sebelum menjalankan `ansible-playbook`. Untuk penulis chart Helm: validasi `values.yaml` atau template chart Anda. Bagi siapa pun yang menulis konfigurasi CI/CD dalam YAML (GitLab CI, CircleCI, Bitbucket Pipelines, Travis CI): tempel konfigurasi dan validasi sebelum push. Dalam semua kasus ini, biaya file YAML yang tidak valid adalah build atau deployment yang gagal — menangkapnya di sini terlebih dahulu selalu lebih cepat.

Asal-usul YAML, filosofinya, dan Masalah Norwegia

YAML — akronim rekursif untuk "YAML Ain't Markup Language" (awalnya "Yet Another Markup Language" ketika Clark Evans dan Ingy döt Net menciptakannya pada 2001) — dirancang di sekitar satu prinsip panduan: keterbacaan manusia dengan tanda baca minimal. Di mana XML membungkus konten dalam tag tanda-kurung-siku dan JSON memerlukan kutipan di sekitar setiap kunci, YAML menggunakan teks polos, indentasi, dan titik dua. Hasilnya adalah konfigurasi yang terbaca hampir seperti prosa. YAML 1.2, diterbitkan pada 2009, memformalkan hubungan penting: setiap dokumen JSON yang valid juga YAML 1.2 yang valid, membuat YAML superset ketat dari JSON dan menyatukan dua format serialisasi paling umum dalam perangkat lunak modern.

Sejarah desain yang bersih itu datang dengan kisah peringatan yang dikenal sebagai Masalah Norwegia. Dalam YAML 1.1 — versi yang diimplementasikan oleh PyYAML, Psych milik Ruby, dan sebagian besar pustaka YAML yang ditulis sebelum 2010 — kata telanjang seperti yes, no, on, off, true, dan false semuanya secara diam-diam dipaksa menjadi boolean. Konfigurasi Kubernetes yang mencantumkan kode negara ISO Norwegia sebagai string NO akan diurai sebagai boolean false, secara diam-diam merusak konfigurasi. Jebakan yang sama menangkap ON (boolean true), off (boolean false), dan puluhan string lain yang tidak bersalah. YAML 1.2 memperbaiki ini dengan membatasi koersi boolean implisit hanya pada true dan false — tetapi perbaikan hanya berlaku untuk parser yang mengimplementasikan 1.2, dan sebagian besar tooling dunia nyata masih menggunakan 1.1 di baliknya. Praktik teraman tetap mengutip nilai string apa pun yang bisa disalahartikan sebagai boolean.

Masalah Norwegia adalah salah satu alasan YAML mendapatkan reputasi mengejutkan pengembang dalam skala besar. Sistem tipe implisitnya — di mana 1.0 menjadi float, 0x1F menjadi bilangan bulat, dan 2024-01-01 menjadi objek tanggal — membuat YAML ekspresif bagi manusia tetapi berbahaya bagi mesin. Memahami versi yang diimplementasikan parser Anda bukan pengetahuan opsional; itu adalah dasar untuk menulis konfigurasi yang portabel. Formatter di sini menargetkan semantik YAML 1.2, yang selaras dengan Kubernetes, yaml.v3 milik Go, dan serde-yaml milik Rust.

Kerentanan keamanan YAML — mengapa parsing yang aman penting

Fitur YAML yang paling berbahaya jarang disebutkan dalam tutorial: eksekusi kode arbitrer selama parsing. PyYAML, pustaka YAML Python yang dominan, mendukung konstruktor tipe kustom melalui sintaks tag !!. Dokumen YAML yang mengandung !!python/object/apply:os.system ["rm -rf /"] akan mengeksekusi perintah shell tersebut saat diurai dengan yaml.load() — tanpa interaksi pengguna, tanpa konfirmasi. Memuat YAML yang tidak dipercaya dengan loader default secara fungsional setara dengan eval(). Perbaikannya selalu menggunakan yaml.safe_load(), yang sepenuhnya menonaktifkan konstruktor kustom dan membatasi parsing ke tipe YAML standar. PyYAML telah mengeluarkan peringatan deprecation tentang ini selama bertahun-tahun, dan Python 3.9+ memerlukan argumen Loader eksplisit untuk membuat pilihan disengaja — tetapi kode lawas yang menggunakan yaml.load() telanjang masih tersebar luas.

Kelas kerentanan yang sama muncul dalam YAML Ruby (Psych) dan memicu salah satu insiden keamanan Rails paling signifikan yang tercatat. Pada Januari 2013, peneliti Charlie Somerville mengungkapkan kerentanan deserialisasi YAML di Rails yang memungkinkan eksekusi kode jarak jauh dengan mengirim payload YAML yang dibuat khusus sebagai parameter permintaan. Kerentanan mass-assignment Rails yang menjadi berita utama saat itu hanyalah sebagian dari ceritanya; RCE deserialisasi YAML adalah temuan yang lebih parah. SnakeYAML, pustaka YAML Java yang banyak digunakan, telah menjadi sumber beberapa CVE profil tinggi — termasuk CVE-2022-1471, yang memengaruhi Spring Boot, dan dieksploitasi di alam liar karena aplikasi menerima YAML dari input pengguna dan meneruskannya langsung ke parser. Polanya konsisten: parser YAML yang mendukung konstruktor tipe adalah gadget deserialisasi yang menunggu untuk dipicu.

Aturan praktisnya sederhana. Jangan pernah memanggil loader tidak aman parser YAML pada konten dari sumber eksternal mana pun — input pengguna, respons API, file yang diunggah pengguna, atau konfigurasi yang ditarik dari repositori yang tidak dipercaya. Selalu gunakan API pemuatan aman (yaml.safe_load() di Python, Psych.safe_load di Ruby, batasi SnakeYAML ke SafeConstructor di Java). Dalam lingkungan browser — yang merupakan cara formatter ini bekerja — parser YAML JavaScript yang digunakan di sini tidak memiliki konsep konstruksi objek bahasa-host, sehingga serangan ini tidak berlaku. Tetapi pipeline sisi-server apa pun yang memproses YAML dari sumber eksternal harus memperlakukan YAML tersebut sebagai input yang tidak dipercaya dan menegakkan parsing aman di tingkat pustaka.

YAML vs JSON vs TOML — memilih format yang tepat

Kekuatan YAML nyata: mendukung komentar inline (# ini komentar — satu-satunya format serialisasi yang banyak digunakan yang melakukannya), string multi-baris dengan gaya blok literal (|) dan blok folded (>), anchor dan alias untuk konfigurasi DRY, dan sintaks yang terbaca alami untuk struktur bertingkat. Properti ini membuatnya menjadi format dominan di dunia cloud dan container — Kubernetes, GitHub Actions, GitLab CI, CircleCI, Ansible, dan Docker Compose semuanya menggunakan YAML sebagai bahasa konfigurasi utama mereka. Format ini dirancang untuk manusia, dan untuk konfigurasi besar itu memenuhi desain tersebut.

Kelemahan YAML sama nyatanya. Spasi kosong yang signifikan berarti spasi ekstra yang tak terlihat atau karakter tab mengubah pohon parsing secara diam-diam. Tab sepenuhnya dilarang — spesifikasi secara eksplisit melarangnya dalam indentasi, tetapi sebagian besar editor tidak membedakan tab dan spasi secara visual. Spesifikasi YAML lengkap memiliki 63 aturan tata bahasa sensitif-konteks, menjadikannya salah satu format paling kompleks untuk diimplementasikan dengan benar; parser berbeda menghasilkan hasil berbeda pada kasus tepi. Sistem tipe implisit (Masalah Norwegia, parsing tanggal, literal bilangan bulat oktal) menambahkan lapisan kejutan lainnya. Kelemahan ini adalah mengapa alat seperti Kustomize, Helm, dan CUE ada — mereka menyediakan lapisan abstraksi di atas YAML Kubernetes mentah persis karena YAML mentah dalam skala besar menjadi masalah pemeliharaan.

JSON lebih sederhana menurut desain: tidak ada spasi kosong yang signifikan, tidak ada tipe implisit, tata bahasa enam-token yang muat di satu halaman, dan dukungan parser universal. Batasan utamanya adalah tidak adanya komentar dan verbositas mengutip setiap kunci. TOML (Tom's Obvious Minimal Language) menargetkan kasus penggunaan file konfigurasi secara langsung: tipe eksplisit, tanpa sensitivitas indentasi, tanpa spasi kosong yang signifikan, dan sintaks yang lebih dekat dengan file INI tradisional. Cargo.toml Rust, pyproject.toml Python, dan file konfigurasi Hugo menggunakan TOML karena lebih sulit salah daripada YAML dan lebih ekspresif daripada JSON untuk konfigurasi. Pilihan yang tepat tergantung konteks: YAML untuk tooling DevOps yang sudah mengharapkannya; JSON untuk API dan pertukaran data; TOML untuk file konfigurasi aplikasi di mana dukungan komentar dan tipe eksplisit lebih penting daripada momentum ekosistem.

Fitur lanjutan YAML — anchor, string multi-baris, dan file multi-dokumen

Anchor dan alias adalah mekanisme bawaan YAML untuk menghindari pengulangan. Anchor didefinisikan dengan &name pada node apa pun, dan alias menggunakan kembali nilai node tersebut dengan *name di mana pun lagi dalam dokumen. Pola umum dalam docker-compose.yml adalah mendefinisikan blok lingkungan bersama sekali dengan anchor dan merujuknya di berbagai definisi layanan — daripada menyalin-tempel sepuluh variabel lingkungan yang sama ke setiap layanan. Kunci merge (<<: *alias) memperluas ini lebih jauh: ia menggabungkan semua pasangan kunci-nilai dari peta yang di-alias ke dalam peta saat ini, memungkinkan definisi layanan dasar diperluas dengan override per-layanan. Ini adalah yang paling dekat YAML dengan pewarisan, dan digunakan secara luas dalam konfigurasi multi-lingkungan.

String multi-baris dalam YAML hadir dalam dua gaya yang melayani tujuan berbeda. Gaya blok literal (|) mempertahankan baris baru persis seperti yang ditulis — setiap jeda baris dalam sumber menjadi jeda baris dalam string yang diurai. Ini adalah pilihan yang tepat untuk menanamkan skrip shell, kueri SQL, atau teks apa pun di mana jeda baris secara semantik penting. Gaya blok folded (>) melipat baris baru menjadi spasi (memperlakukan blok seperti paragraf), sambil mempertahankan baris kosong sebagai jeda paragraf. Ini cocok untuk nilai prosa panjang — string dokumentasi, deskripsi, pesan kesalahan — di mana Anda ingin hard-wrap dalam sumber untuk keterbacaan tetapi mengirimkan string tunggal yang tidak terputus ke konsumen. Kedua gaya mendukung indikator chomping: |- menghapus baris baru terakhir, |+ mempertahankan semua baris baru trailing, dan | telanjang mempertahankan tepat satu.

YAML multi-dokumen memungkinkan beberapa dokumen YAML independen hidup berdampingan dalam satu file, dipisahkan oleh penanda mulai dokumen ---. Penanda akhir dokumen opsional ... menutup dokumen secara eksplisit. Kubernetes menggunakan pola ini secara luas — satu file manifest.yaml bisa berisi Deployment, Service, dan ConfigMap, masing-masing dipisahkan oleh ---, diterapkan bersama dengan satu kubectl apply -f manifest.yaml. Pemisah --- juga berfungsi sebagai batas versi dalam konteks YAML streaming, di mana produsen mungkin mengeluarkan urutan dokumen yang tidak terbatas melalui koneksi dan konsumen memproses masing-masing saat tiba. Formatter ini mendukung file multi-dokumen: setiap dokumen diurai secara independen, kesalahan dilaporkan per-dokumen, dan konversi JSON membungkus semua dokumen dalam array tingkat-teratas.