Ringkas: JSON memiliki tata bahasa yang kecil dan ketat — kesalahan yang merusak parser (koma di akhir, kunci tanpa tanda kutip, tanda kutip tunggal) tak terlihat dalam data yang diminifikasi tapi jelas setelah diformat. Mengetahui aturan sintaks yang sebenarnya mengubah "API mengembalikan kesalahan" menjadi perbaikan dua detik. Padukan panduan ini dengan Encoding Converter, Character Counter, Text Difference, dan AI Hidden Characters.

Memformat JSON berarti menambahkan spasi kosong dan indentasi untuk membuat strukturnya terbaca; memvalidasinya berarti memeriksa apakah struktur itu benar-benar mengikuti tata bahasa yang didefinisikan dalam RFC 8259. JSON yang diminifikasi — bentuk padat tanpa spasi yang sebenarnya dikirimkan API — benar tapi tidak terbaca; pemformat membalikkan itu tanpa mengubah datanya.

Aturan sintaks yang benar-benar penting

Kunci JSON harus berupa string dalam tanda kutip ganda — {name: "nilai"} tidak valid, hanya {"name": "nilai"} yang berhasil diurai. Tanda kutip tunggal tidak pernah valid untuk string atau kunci, berbeda dari literal objek JavaScript, yang sintaks JSON sengaja dibatasi. Koma di akhir setelah elemen terakhir dalam array atau objek — ["a", "b",] — adalah JSON yang tidak valid, meskipun tidak berbahaya (atau bahkan diperlukan menurut konvensi) dalam beberapa bahasa lain, dan ini adalah salah satu alasan paling umum mengapa JSON yang diedit manual gagal diurai.

Mengapa "terlihat benar" bukan sama dengan valid

Dokumen JSON bisa secara visual tidak bisa dibedakan dari yang valid dan tetap gagal diurai — kurung kurawal penutup yang hilang di akhir struktur bersarang besar, tanda kutip pintar () yang ditempel dari pengolah kata alih-alih tanda kutip lurus ", atau komentar yang tersasar (JSON sama sekali tidak punya sintaks komentar, berbeda dari JSON5 atau JSONC) semuanya akan merusak parser ketat sambil terlihat baik-baik saja sekilas. Inilah tepatnya mengapa memformat sebelum melihat membantu: indentasi yang benar membuat kurung kurawal yang tidak tertutup terlihat jelas secara visual, dengan memecah pola bersarang yang diharapkan.

Pemformatan vs. validasi skema

Pemformat memeriksa bahwa JSON valid secara sintaksis — kurung seimbang, string dikutip dengan benar, tidak ada koma di akhir. Ia tidak memeriksa apakah data masuk akal: apakah bidang yang seharusnya angka sebenarnya adalah string, atau bidang yang diperlukan hilang. Itu adalah masalah terpisah, ditangani oleh validasi JSON Schema, yang memeriksa struktur dan tipe terhadap definisi skema alih-alih hanya memeriksa bahwa JSON itu sendiri terbentuk dengan baik.

Alur kerja untuk JSON yang berantakan atau rusak

  1. Tempel JSON mentah — diminifikasi, rusak, atau lainnya — dulu ke pemformat.
  2. Jika berhasil diurai, tinjau struktur berindentasi untuk menemukan bidang atau nilai yang sebenarnya Anda cari.
  3. Jika gagal diurai, periksa dulu lokasi kesalahannya: sebagian besar parser melaporkan baris/kolom, yang biasanya menunjuk langsung ke koma, kurung, atau tanda kutip yang hilang.
  4. Perhatikan khusus koma di akhir dan tanda kutip pintar ketika sumbernya diketik manual atau ditempel dari editor bukan-kode.

Kesalahan umum yang harus dihindari

  • Berasumsi indentasi yang terlihat valid berarti JSON valid — pemformatan dan penguraian adalah langkah terpisah.
  • Menambahkan koma di akhir karena kebiasaan dari JavaScript atau Python, di mana itu sering ditoleransi.
  • Menempel JSON dari pengolah kata dan mendapatkan tanda kutip pintar melengkung alih-alih lurus.
  • Mencampuradukkan "berhasil diformat tanpa kesalahan" dengan "cocok dengan skema yang diharapkan API" — itu adalah pemeriksaan yang berbeda.

Sebagian besar kesalahan JSON adalah satu karakter spesifik di satu tempat spesifik — nilai sebenarnya dari pemformat adalah membuat tempat itu terlihat alih-alih membiarkan Anda memindai satu baris tidak terputus untuk menemukannya.