Format JSON

Apa yang diterima formatter ini

Parser mengikuti RFC 8259 dengan tepat, yang lebih ketat dari perkiraan kebanyakan orang. Kunci harus memakai tanda kutip ganda. String harus memakai tanda kutip ganda, tidak pernah tanda kutip tunggal. Tidak boleh ada koma setelah elemen terakhir objek atau array, tidak ada sintaks komentar dalam bentuk apa pun, dan tidak ada NaN, Infinity, atau undefined. Angka tidak boleh ditulis dalam heksadesimal, tidak boleh diawali tanda plus, dan bagian bilangan bulatnya tidak boleh diawali nol.

Keketatan ini disengaja, bukan cerewet: inilah aturan yang akan diterapkan setiap parser JSON di sisi penerima. Dokumen yang bisa diformat di sini akan terbaca di Python, Go, Rust, dan PostgreSQL. Dokumen yang hanya berjalan setelah parser yang longgar menebak maksud Anda akan gagal di suatu tempat nanti, biasanya di produksi.

Jika input Anda berisi komentar atau koma di akhir, itu bukan JSON melainkan JSON5 atau JSONC, varian longgar yang dipakai file konfigurasi seperti tsconfig.json. Keduanya format sungguhan dengan kegunaan nyata, dan menghapus komentar agar dokumen menjadi JSON valid adalah perubahan yang menghilangkan informasi. Lakukan dengan sadar.

Membaca pesan error

Saat parsing gagal, error menyertakan baris dan kolom yang dihitung dari posisi karakter yang dilaporkan engine. Perlu diingat, posisi itu adalah tempat parser menyerah, tidak selalu tempat Anda membuat kesalahan: kurung kurawal penutup yang hilang biasanya dilaporkan di akhir dokumen, karena semua isi sampai titik itu masih mungkin valid.

Empat penyebab yang menjelaskan hampir semua kegagalan adalah koma sebelum kurung penutup, tanda kutip tunggal di sekitar string atau kunci, kunci tanpa tanda kutip yang disalin dari object literal JavaScript, dan tanda kutip ganda atau baris baru yang tidak di-escape di dalam nilai string. Jika kolom yang dilaporkan menunjuk ke tanda kutip, kemungkinan string sebelumnya berakhir terlalu cepat.

Kasus umum lainnya adalah dokumen yang terpotong. Respons yang terpotong karena batas ukuran atau timeout akan terurai dengan normal sampai berhenti di tengah nilai, sehingga error muncul di baris terakhir, bukan di tempat yang informatif. Periksa akhir input sebelum mencari di bagian tengah.

Apa yang berubah saat diurai lalu ditulis ulang

Memformat berarti mengurai dokumen lalu menserialisasinya lagi, jadi beberapa hal dinormalisasi di tengah jalan, dan ada baiknya tahu apa saja.

Angka menjadi double IEEE 754. Bilangan bulat yang lebih besar dari 9.007.199.254.740.991 kehilangan presisi, dan ini penting karena ID database 64-bit, ID snowflake ala Twitter, dan timestamp nanodetik semuanya berada di atas batas itu. ID 9223372036854775807 kembali sebagai 9223372036854776000. Jika nilai itu harus utuh, simpan sebagai string di payload. Nol di belakang juga hilang: 1.0 diformat menjadi 1, dan 1e3 menjadi 1000.

Kunci ganda digabung dan yang terakhir menang, karena tahap parsing membangun sebuah objek. Selain itu urutan kunci dipertahankan, dengan satu pengecualian yang diwarisi dari objek JavaScript: kunci yang terlihat seperti bilangan bulat non-negatif diurutkan secara numerik dan dipindahkan ke depan kunci lainnya. Komentar dan spasi asli tentu hilang, karena keduanya tidak bertahan setelah parsing.

Tampilan pohon

Di atas teks yang sudah diformat ada tampilan pohon yang bisa dilipat. Fungsinya berbeda: memahami bentuk respons yang belum dikenal, letak field yang dicari, dan seberapa dalam field itu bersarang, tanpa menggulir ribuan baris yang diindentasi. Lipat array yang tidak Anda perlukan, dan strukturnya bisa terbaca dalam satu layar.

Tombol salin selalu menyalin teks yang sudah diformat, jadi menjelajah di tampilan pohon tidak pernah mengubah apa yang Anda tempel kembali ke editor.

Asal usul JSON dan apa yang bisa ditampungnya

JSON dirumuskan oleh Douglas Crockford pada awal 2000-an sebagai bagian dari sintaks objek literal JavaScript, berangkat dari pengamatan bahwa peramban sudah bisa menguraikannya dan bahwa XML terlalu berat untuk kebutuhan kebanyakan API web. Ia dibakukan sebagai RFC 4627, lalu digantikan oleh RFC 8259 dan ECMA-404, dan kenyataan bahwa seluruh tata bahasanya muat dalam satu halaman menjelaskan sebagian besar alasan ia begitu mendominasi.

Model datanya sengaja dibuat kecil: objek, array, string, angka, boolean, dan null. Hanya itu. Tidak ada tipe tanggal, tidak ada tipe biner, tidak ada pembedaan bilangan bulat dan pecahan, tidak ada komentar, dan tidak ada cara menyatakan rujukan dari satu bagian dokumen ke bagian lain.

Semua hal yang merepotkan pada JSON berasal dari daftar itu. Tanggal terpaksa menjadi kesepakatan, bukan tipe; data biner harus disandikan sebagai teks; bilangan bulat besar membebani format yang angkanya biasanya diurai sebagai double; dan berkas konfigurasi - yang butuh komentar - harus memakai dialek atau format lain sama sekali.

Tanggal, uang, dan angka besar

Untuk tanggal, kesepakatan yang sudah mapan adalah ISO 8601 dalam UTC, seperti 2026-03-14T09:30:00Z. Formatnya terurut secara leksikografis, tidak ambigu, dan bisa diurai oleh semua bahasa pemrograman. Pilihan lain menimbulkan masalah: timestamp Unix kehilangan pembedaan antara detik dan milidetik, sedangkan string terlokalisasi seperti 03/14/2026 menjadi ambigu di luar negara yang menulisnya.

Uang sebaiknya tidak ditulis sebagai angka JSON. Parser boleh memakai bilangan pecahan presisi ganda, sehingga persoalan 0.1 ditambah 0.2 ikut datang bersama payload, dan perilaku pembulatan berbeda antarbahasa. Satuan terkecil dalam bilangan bulat - 1999 untuk £19.99 - dengan mata uang di field terpisah adalah representasi yang bertahan di tangan konsumen mana pun.

Identifier besar menghadapi persoalan yang sama dalam bentuk yang lebih tajam. Nilai apa pun di atas 2^53 kehilangan presisi ketika diurai menjadi double, dan itu mencakup id basis data 64-bit serta identifier bergaya snowflake, jadi semuanya sebaiknya dikirim sebagai string di dalam payload. Ini bukan kekhawatiran teoretis: itulah sebabnya beberapa API besar mengembalikan field id dan id_str sekaligus.

Berkas yang terlalu besar untuk dimuat di memori

Parser yang membangun seluruh dokumen sebagai objek membutuhkan memori beberapa kali lipat ukuran berkasnya, sehingga ekspor sebesar 500 MB bisa menghabiskan jatah sebuah proses di mesin yang masih punya sisa memori bergigabyte. Ada dua pendekatan untuk menghindarinya.

Yang pertama adalah JSON berpembatas baris baru, yang setiap barisnya merupakan satu dokumen utuh sementara berkasnya secara keseluruhan bukan JSON yang sah. Format ini mengalir secara alami, murah untuk ditambahi baris baru, dan dipakai oleh sebagian besar pipeline log serta format ekspor massal. Yang kedua adalah parser streaming - ijson di Python, pembaca bergaya SAX di bahasa lain - yang memancarkan event sambil menelusuri berkas dan tidak pernah mewujudkan seluruh pohonnya di memori.

Di baris perintah, jq menangani keduanya dan memang layak dipelajari: jq '.items[] | {id, name}' big.json mengambil proyeksi yang Anda butuhkan tanpa memuat dokumen ke dalam editor. Flag --stream miliknya menangani kasus ketika mode bawaan jq pun akan memakai terlalu banyak memori.

Permukaan keamanan sebuah payload JSON

Penguraian JSON itu sendiri aman di bahasa modern mana pun; risikonya ada pada apa yang terjadi setelahnya. Yang paling terkenal adalah prototype pollution: di JavaScript, menggabungkan JSON yang dikendalikan penyerang ke dalam sebuah objek tanpa penyaringan bisa menetapkan __proto__ dan mengubah perilaku setiap objek dalam proses itu. Utilitas deep-merge berulang kali merilis bug ini, dan pertahanannya adalah menolak kunci semacam itu secara eksplisit atau memakai objek tanpa prototipe.

Jangan pernah mengevaluasi JSON. Menguraikannya dengan eval memang praktik nyata pada masa sebelum JSON.parse ada, tetapi cara itu mengeksekusi apa pun yang masuk. Kode apa pun yang hari ini memakai eval pada data adalah temuan keamanan, bukan sekadar soal selera gaya penulisan.

Ada dua hal yang lebih kecil namun layak diketahui. Menyajikan array JSON dengan content type yang akan dieksekusi peramban adalah dasar dari serangan JSON hijacking di masa lalu, dan itulah alasan beberapa API sampai sekarang masih menambahkan baris pemutus perulangan di awal responsnya. Selain itu, kunci ganda sah menurut tata bahasanya tetapi ditangani berbeda oleh tiap parser, dan hal ini pernah dipakai untuk menyelundupkan nilai yang berbeda melewati validator dari nilai yang akhirnya dibaca aplikasi.

Dialek-dialeknya, dan kapan memakainya

JSON5 menambahkan komentar, koma di akhir, kunci tanpa tanda kutip, dan string berkutip tunggal. JSONC adalah varian yang lebih kecil, dipakai Visual Studio Code untuk berkas pengaturannya dan tsconfig.json - pada dasarnya JSON ditambah komentar. Keduanya bukan JSON, dan keduanya tidak akan bisa diurai pustaka standar tanpa paket khusus.

Pembeda yang benar-benar penting adalah siapa pembacanya. Berkas yang dirawat manusia memperoleh manfaat sangat besar dari komentar, jadi JSON5, JSONC, YAML, atau TOML sama-sama masuk akal di sana. Sebaliknya, payload yang melintasi jaringan sebaiknya JSON biasa, karena penerimanya bisa bahasa apa saja dengan versi pustaka apa saja, dan memakai dialek berarti menukar jaminan interoperabilitas dengan sebuah ketergantungan.

Ketika Anda menempelkan berkas konfigurasi ke parser yang ketat lalu gagal, biasanya itu berarti berkasnya memakai sebuah dialek, bukan rusak. Membuang komentarnya agar diterima parser adalah penyuntingan yang menghilangkan dokumentasi tulisan orang lain, jadi lakukanlah pada salinan.