Cara memformat dan memvalidasi JSON: panduan developer

JSON ada di mana-mana: respons API, file konfigurasi, log, antrean pesan, payload request, kolom database. Untuk format yang sesederhana itu, mengejutkan betapa sering ia menjadi sumber masalah. Koma yang hilang merusak deployment, whitespace ekstra membuat dua file tampak “berbeda” padahal seharusnya identik, struktur bersarang yang dalam hampir tidak mungkin di-debug kalau tidak diindentasi.

Ini panduan praktis untuk bekerja dengan JSON secara bersih: apa yang format ini benar-benar butuhkan, cara membuatnya mudah dibaca, cara memvalidasinya, dan kebiasaan kecil yang mencegah bug JSON lolos ke production.

Apa yang sebenarnya diizinkan JSON

Spesifikasi JSON sengaja kecil. Dokumen JSON adalah salah satu dari:

• Sebuah object: { "key": value, ... }
• Sebuah array: [ value, ... ]
• Sebuah string: "text" (selalu dikutip ganda, tidak pernah dikutip tunggal)
• Sebuah number: 42, 3.14, -2.5e10
• Sebuah boolean: true atau false
• null

Itu saja. Tidak ada komentar. Tidak ada trailing comma. Tidak ada key tanpa kutip. Tidak ada string dengan kutip tunggal. Tidak ada undefined. Tidak ada NaN atau Infinity. Tidak ada fungsi.

Jika Anda pernah bertanya mengapa parser JSON menolak file Anda yang “jelas valid”, biasanya salah satu dari ini:

{
 "name": "Alice",
 "age": 30, // ← komentar: TIDAK valid JSON
 "email": 'alice@...', // ← kutip tunggal: TIDAK valid JSON
 role: "admin", // ← key tanpa kutip: TIDAK valid JSON
 "active": true, // ← trailing comma: TIDAK valid JSON
}

Format yang memang mengizinkan relaksasi ini adalah JSON5 (mengizinkan komentar, trailing comma, key tanpa kutip) dan JSONC (JSON with Comments, digunakan oleh file konfigurasi VS Code). Mereka adalah superset JSON tetapi memerlukan parser khusus.

Aturan pemformatan yang membuat JSON dapat dibaca

JSON yang diminifikasi terlihat seperti ini:

{"users":[{"id":1,"name":"Alice","roles":["admin","editor"]},{"id":2,"name":"Bob","roles":["viewer"]}]}

JSON yang diformat terlihat seperti ini:

{
 "users": [
 {
 "id": 1,
 "name": "Alice",
 "roles": ["admin", "editor"]
 },
 {
 "id": 2,
 "name": "Bob",
 "roles": ["viewer"]
 }
 ]
}

Data yang sama, keterbacaan yang sama sekali berbeda.

Aturan pemformatan yang penting:

• Indentasi: 2 spasi. Ini sejauh ini konvensi yang paling umum. Beberapa codebase menggunakan 4; tab jarang. Konsisten dalam proyek.
• Satu key per baris di dalam object, satu item per baris di dalam array (untuk array dari konten non-sepele)
• Spasi setelah titik dua, tanpa spasi sebelumnya: "key": value
• Array primitif dalam satu baris saat pendek: "roles": ["admin", "editor"] baik-baik saja
• Array object dalam beberapa baris selalu - jika tidak, mereka menjadi tidak terbaca dengan cepat

JSON Formatter kami menerapkan semua ini secara otomatis saat Anda klik Format.

Memvalidasi JSON: apa yang harus dicari

Sebelum file JSON berguna, ia harus valid. Kegagalan validasi umum:

1. Koma yang hilang atau ekstra

Sejauh ini yang paling umum. JSON yang secara sintaksis tidak valid hampir selalu memiliki masalah koma.

{
 "a": 1,
 "b": 2 ← koma yang hilang
 "c": 3
}

Lokasi kesalahan: parser menyalahkan baris setelah koma yang hilang, yang bisa menyesatkan.

2. String yang tidak ditutup

Baris baru yang nyasar di dalam string, atau kutip penutup yang hilang:

{ "name": "Alice
} 

JSON tidak mengizinkan baris baru literal di dalam string. Anda harus meng-escape-nya sebagai \n.

3. Bracket yang tidak cocok

Satu } atau ] ekstra di mana pun dalam file:

{
 "users": [{"name": "Alice"}]}
}

Sebagian besar parser melaporkan bracket pertama yang tidak cocok, yang mungkin jauh dari kesalahan sebenarnya.

4. Angka yang tidak valid

Angka JSON mengikuti aturan ketat: tanpa leading +, tanpa nol di depan (kecuali 0.x), tanpa 1. tanpa digit berikutnya, tanpa .5 tanpa nol di depan.

{ "a": +5, "b": 07, "c": 1., "d": .5 } ← semua tidak valid

5. Karakter yang di-escape dalam string

Backslash dan kutip di dalam string harus di-escape:

{ "path": "C:\Users\Alice" } ← tidak valid (backslash tidak di-escape)
{ "path": "C:\\Users\\Alice" } ← valid

6. Key duplikat

Secara teknis spec JSON mengatakan key duplikat “diizinkan tetapi tidak disarankan.” Dalam praktiknya, sebagian besar parser secara diam-diam mengambil nilai terakhir. Ini hampir selalu bug.

{ "name": "Alice", "name": "Bob" }

Cara memformat dan memvalidasi dalam praktik

Alur kerja tercepat untuk sebagian besar developer:

1. Tempel JSON yang dicurigai ke dalam formatter
2. Klik Format
3. Jika diterima, baca output yang diformat untuk memahami struktur
4. Jika ditolak, baca pesan kesalahan dengan hati-hati - nomor baris biasanya dekat dengan (tetapi tidak persis pada) masalah sebenarnya

JSON Formatter kami melakukan persis ini. Ia menggunakan JSON.parse bawaan browser (parser yang sama yang digunakan oleh setiap API Node.js dan layanan web), jadi pesan kesalahan apa pun yang Anda lihat adalah yang sama yang akan dipancarkan oleh API JSON sebenarnya.

Toggle minify / format

Formatter biasanya punya dua tombol: Format (atau Beautify, Pretty-print) yang menambahkan whitespace dan indentasi untuk keterbacaan, dan Minify (atau Compact) yang menghapus semua whitespace yang tidak perlu.

JSON minified dipakai saat ukuran byte penting — dikirim lewat jaringan, disimpan di database, dimasukkan ke URL. Secara fungsional identik dengan JSON terformat, hanya jauh lebih kecil untuk dokumen besar.

Diformat: 1.240 byte
Diminifikasi: 680 byte (-45%)

Untuk respons API production, selalu minify. Untuk file konfigurasi, log, dan apa pun yang akan dibaca manusia, selalu format.

Alat di luar formatter

Setelah JSON terformat dan valid, kadang Anda butuh lebih. JSON schema mendefinisikan field apa yang harus ada dalam dokumen yang valid, termasuk tipe dan batasan — berguna kalau Anda ingin menegakkan bentuk yang konsisten di banyak dokumen. JMESPath / jq adalah bahasa kueri untuk mengekstrak atau mengubah JSON; jq adalah alat command line yang de facto. JSON diff menunjukkan apa yang berubah antara dua dokumen JSON, jauh lebih berguna dari text diff biasa.

Ini biasanya tidak diperlukan untuk pemformatan sehari-hari. Tapi kalau Anda rutin bekerja dengan JSON, semua ini layak dikenal.

Cheatsheet referensi cepat

Kebutuhan	Apa yang harus dilakukan
Membuat JSON dapat dibaca	Format dengan indent 2 spasi
Mengecilkan untuk transport	Minify
Menemukan kesalahan sintaks	Tempel ke formatter, catat lokasi kesalahan
Memeriksa apakah dua dokumen “sama”	Minify keduanya dan bandingkan byte per byte, atau gunakan JSON diff yang tepat
Menambahkan validasi struktur	Gunakan JSON Schema
Menyimpan dalam URL atau cookie	Minify dan URI-encode

Kebiasaan yang layak dibangun

Jangan pernah menempelkan JSON mentah ke email, pesan chat, atau issue tracker tanpa memformatnya dulu. JSON minified di issue GitHub hampir tidak terbaca dan membuang waktu semua orang. Tiga puluh detik di formatter mengubah tembok teks jadi struktur yang bisa dibaca.

Saat debugging respons API nyata, alirkan dulu melalui formatter sebelum mencoba memahaminya. Kebiasaan ini menghemat banyak menit frustrasi yang seharusnya tidak perlu terjadi.

---

JSON Formatter kami berjalan di browser — tanpa upload, tanpa server round-trip, tidak ada yang dicatat di mana pun. Tempel JSON, klik Format atau Minify, klik Copy, selesai. Pesan kesalahan yang Anda lihat persis sama dengan yang akan dilempar kode Anda saat memanggil JSON.parse(), jadi tidak ada kejutan.

JSON ada di mana-mana, dan bekerja dengannya dengan rapi tetap merupakan keterampilan yang berdampak nyata — commit yang lebih bersih, bug yang lebih mudah dilacak, review yang lebih cepat. Tiga puluh detik per dokumen, layak dilakukan.