Pemformat JSON

JSON formatter dan validator gratis yang tidak pernah mengunggah data Anda

JSON formatter dan JSON validator milik UtiloKit menangani seluruh alur kerja untuk bekerja dengan data JSON — tanpa daftar, tanpa instalasi, dan tidak ada yang pernah dikirim ke server. Tempel JSON Anda, seret file, atau ketik langsung di editor, dan langsung validasi sintaks, beautify atau minify output, jelajahi tree yang bisa dicari dan dilipat, urutkan key, dan konversi ke format lain — semuanya dalam satu tab browser. Tool seperti JSONLint, JSONFormatter.org, jsoneditoronline.org, CodeBeautify JSON, dan JSON Crack masing-masing mencakup bagian dari alur kerja ini, tapi semuanya memproses data Anda di sisi server. UtiloKit menjaga setiap operasi 100% client-side, membuatnya aman untuk API key, token OAuth, connection string, PII, dan apa pun lainnya yang Anda tidak ingin kirim ke server pihak ketiga.

Tool ini menangani segalanya mulai dari cek sintaks cepat pada respons API yang ditempel hingga memvalidasi dan memformat ulang file konfigurasi produksi multi-ribu baris. Pintasan keyboard, pemuatan file drag-and-drop, salin ke clipboard, dan unduhan sekali klik semuanya sudah built-in. Layout yang responsif bekerja baik di mobile maupun di monitor desktop lebar. Bookmark tool ini dan Anda akan selalu punya workspace JSON yang andal dan privat setiap kali Anda membutuhkannya.

Validasi JSON real-time dengan lokasi error persis

JSON validator yang berguna tidak sekadar bilang 'tidak valid' — ia memberi tahu Anda persis di mana masalahnya. Saat Anda mengetik atau menempel, validator online ini terus mengurai JSON Anda dan melaporkan nomor baris dan kolom persis dari setiap error sintaks: token tak terduga, koma berlebih, titik dua hilang, string tidak ditutup, kurung tidak cocok, urutan escape tidak valid, dan karakter kontrol gaya-JavaScript yang telanjang. Setiap pesan ditulis dalam bahasa yang jelas — 'Unexpected token } at line 14, column 3' alih-alih stack trace parser mentah — sehingga Anda bisa langsung menuju perbaikannya. Semua error dalam satu dokumen ditampilkan sekaligus sehingga Anda bisa menyelesaikannya dari atas ke bawah dalam satu kali jalan, berbeda dengan JSONLint yang hanya menampilkan satu error dalam satu waktu dan mengharuskan pengiriman ulang setelah tiap perbaikan.

Aktifkan mode Repair / JSONC dan validator menjadi toleran terhadap ekstensi non-standar dunia nyata yang umum: komentar baris //, komentar blok /* */, dan koma berlebih setelah elemen terakhir. Ini mencakup file konfigurasi yang benar-benar dipakai developer setiap hari — tsconfig.json, .eslintrc, .babelrc, pengaturan workspace VS Code, konfigurasi Prettier, dan konfigurasi Jest — yang seharusnya ditolak mentah-mentah oleh parser JSON ketat.

Beautify, minify, dan urutkan — dengan kontrol penuh atas format output

Sebagai JSON beautifier, tool ini melakukan pretty-print pada data terkompresi atau terminifikasi dengan pilihan indentasi 2 spasi, 4 spasi, atau tab, dirender dengan syntax highlighting berwarna dan gutter nomor baris. Satu klik meminifikasi JSON menjadi payload valid terkecil — menghapus semua whitespace dan baris baru — untuk respons HTTP API, penyimpanan log yang ringkas, field dokumen database, atau konteks mana pun di mana ukuran payload penting. Statistik ukuran byte langsung menampilkan perbandingan sebelum-dan-sesudah persis dalam byte dan persentase pengurangan.

Sort keys mengurutkan secara alfabetis semua key objek secara rekursif di setiap tingkat bertingkat dalam satu operasi — berguna untuk membandingkan dua representasi JSON dari data yang sama tapi kebetulan key-nya berbeda urutan, untuk menormalkan respons API menjadi bentuk kanonik untuk caching deterministik, atau untuk mengaudit file konfigurasi besar di mana urutan key yang konsisten membuat pemindaian lebih cepat. Gabungkan sort, beautify, dan minify secara bebas — sort → minify menghasilkan JSON minimal kanonik yang cocok sebagai input cache key atau content hash.

Tree view yang bisa dicari — navigasi JSON kompleks di kedalaman berapa pun

Tree view JSON mengubah bahkan dokumen bertingkat dalam menjadi struktur yang bisa dinavigasi dan dilipat. Perluas atau lipat node individual dengan satu klik, atau gunakan 'Expand all' / 'Collapse all' untuk beralih antara tampilan penuh dan ringkasan tingkat atas. Ketik di kotak pencarian untuk menyaring tree yang terlihat hanya ke node yang key atau value-nya cocok dengan query Anda — semua cabang yang tidak cocok memudar sementara path yang cocok tetap terlihat, memungkinkan Anda menemukan field tertentu dalam dokumen seribu-key dalam hitungan detik.

Klik node mana pun untuk menyalin path dot-notation lengkapnya ke clipboard — misalnya, response.data.users[3].profile.email. Path itu langsung bisa dipakai dalam query JSONPath, kode ekstraksi JavaScript, script pipeline data Python, atau dokumentasi API. Tree view juga menampilkan tipe nilai dan panjang array secara inline, memberi Anda konteks struktural sekilas tanpa perlu scroll ke kurung penutup objek bertingkat.

Konversi JSON ke YAML, CSV, XML, dan TypeScript dalam satu klik

Sebagai JSON converter, UtiloKit mengubah JSON valid menjadi empat format yang benar-benar dibutuhkan developer. JSON ke YAML menghasilkan YAML yang bersih dan berindentasi rapi untuk manifest Kubernetes, Helm chart, workflow GitHub Actions, dan file konfigurasi aplikasi. JSON ke CSV mengubah array objek menjadi baris koma-terpisah dengan key objek sebagai header kolom — tempel langsung ke Excel, Google Sheets, atau Tableau. JSON ke XML membungkus setiap key dalam tag XML untuk integrasi enterprise dan payload layanan SOAP. JSON ke TypeScript menghasilkan definisi interface siap-pakai dari sampel JSON, menyimpulkan tipe yang benar dan bentuk bertingkat untuk langsung dipakai di codebase Anda.

Konversi kebalikan didukung sama baiknya: tempel YAML, CSV, atau XML untuk mengonversi masing-masing kembali menjadi JSON yang diformat dengan baik dalam sesi yang sama. Escaping dan unescaping string melengkapi toolkit ini. Setiap konversi berjalan sebagai JavaScript client-side — CSV berisi PII, konfigurasi YAML dengan kata sandi database, atau file TypeScript dengan detail arsitektur internal tidak pernah meninggalkan browser Anda. Tidak ada round-trip ke server, tidak ada layanan pihak ketiga di tengah-tengah.

Kenapa UtiloKit lebih aman dari JSONLint, JSONFormatter.org, CodeBeautify, dan JSON Crack

Kebanyakan tool JSON online populer — termasuk JSONLint, JSONFormatter.org, jsoneditoronline.org, CodeBeautify JSON, dan JSON Crack — mengirim data Anda ke server mereka sebelum memprosesnya. Untuk JSON yang tersedia untuk publik seperti contoh respons API atau data tutorial, itu trade-off yang bisa diterima. Tapi JSON dunia nyata sering mengandung hal-hal yang tidak seharusnya Anda kirim ke pihak ketiga: API key, bearer token OAuth, connection string database, URL microservice internal, alamat email pelanggan, PII, catatan finansial, dan konfigurasi bisnis rahasia. UtiloKit menghilangkan risiko ini sepenuhnya: semua operasi dieksekusi sebagai JavaScript lokal di browser Anda tanpa request jaringan keluar untuk data Anda.

Tidak ada daftar akun, tidak ada paywall, tidak ada batas rate, tidak ada batasan ukuran file, tidak ada watermark pada output, dan tidak ada iklan di antarmuka editor. Pintasan keyboard, pemuatan file drag-and-drop, salin ke clipboard, dan unduhan file semuanya sudah built-in. Layout responsifnya bekerja di mobile tanpa aplikasi khusus, dan tool penuhnya berfungsi offline setelah halaman dimuat — andal di pesawat, di jaringan korporat yang dibatasi, dan bagi siapa pun yang sekadar lebih suka tidak mengekspos data operasional sensitif ke layanan pihak ketiga yang tidak dikenal.

Spesifikasi JSON: apa yang sebenarnya disyaratkan RFC 8259

RFC 8259, diterbitkan pada 2017, adalah spesifikasi JSON otoritatif saat ini. Ia menggantikan RFC 7159 (2014), yang sendiri menggantikan RFC 4627 asli (2006). Spesifikasinya singkat — kurang dari 15 halaman — tapi secara presisi mendefinisikan apa yang membentuk JSON valid. String harus memakai tanda kutip ganda, bukan tunggal: 'hello' adalah error sintaks di mana "hello" valid. Key objek juga harus berupa string berkutip ganda: key telanjang seperti {name: "Alice"} adalah JSON tidak valid meskipun itu sintaks JavaScript yang sah. Koma berlebih tidak diperbolehkan: elemen terakhir dalam array atau objek tidak boleh diikuti koma, meski ini salah satu kesalahan paling umum yang dilakukan developer saat menulis JSON manual atau mengadaptasi literal objek JavaScript. Komentar bukan bagian dari spesifikasi JSON — meski betapa umumnya mereka muncul di format konfigurasi turunan-JSON. Douglas Crockford, yang merancang JSON, secara publik menyatakan bahwa komentar sengaja dihilangkan untuk mencegah pemakaiannya sebagai directive parsing yang bisa menciptakan ketidakcocokan antar implementasi.

Di luar sintaks, ada beberapa konstruksi JavaScript yang sering diharapkan developer didukung JSON tapi secara eksplisit dikecualikan oleh spesifikasi. undefined tidak punya padanan JSON — JSON punya null tapi bukan undefined, sehingga mensrialisasi objek JavaScript dengan properti bernilai undefined biasanya diam-diam menghilangkan key tersebut. Infinity dan NaN bukan nilai numerik JSON yang valid — spesifikasi mendefinisikan angka memakai grammar desimal terbatas, sehingga serializer yang menghasilkan {"ratio": Infinity} atau {"score": NaN} menghasilkan JSON tidak valid yang akan ditolak dengan error oleh kebanyakan parser. Karakter kontrol yang tidak di-escape — kode poin Unicode U+0000 hingga U+001F — harus di-escape dengan urutan backslash di dalam string; newline atau tab mentah yang disematkan langsung dalam nilai string JSON adalah pelanggaran spesifikasi. Key objek duplikat secara teknis diizinkan oleh grammar-nya tapi perilakunya secara eksplisit dibiarkan tidak didefinisikan: spesifikasi mengatakan parser boleh memilih memakai nilai pertama, nilai terakhir, atau memberi sinyal error, dan dalam praktiknya kebanyakan parser diam-diam mengadopsi kemunculan terakhir. Mengandalkan key duplikat untuk tujuan apa pun yang disengaja adalah bahaya portabilitas.

Memahami batasan-batasan ini menjelaskan kenapa begitu banyak file konfigurasi JSON yang terlihat valid sebenarnya adalah JSONC — JSON with Comments, sebuah superset yang bukan JSON standar dan hanya bisa diparsing oleh parser yang sadar-JSONC. tsconfig.json milik TypeScript, settings.json milik VS Code, .eslintrc.json milik ESLint, .prettierrc milik Prettier, dan .babelrc milik Babel semuanya umum muncul dengan sintaks komentar dan koma berlebih yang ditolak parser RFC 8259 ketat. Ini bukan kelalaian — tool-tool ini sengaja memilih format konfigurasi yang lebih ergonomis dan menyertakan parser mereka sendiri. Implikasi praktisnya adalah Anda tidak bisa dengan aman memasukkan file ini ke panggilan JSON.parse() tanpa terlebih dahulu menghilangkan sintaks non-standarnya, yang persis apa yang dilakukan mode Repair / JSONC UtiloKit secara otomatis.

JSON dalam desain API: REST, JSON:API, JSON-RPC, dan format streaming

JSON melampaui XML sebagai format dominan untuk respons REST API antara sekitar 2010 dan 2012, karena alasan praktis yang tetap berlaku hari ini. JSON tidak memiliki tag penutup, sehingga objek tiga-field seperti {"id": 1, "name": "Alice", "role": "admin"} mungkin hanya memakan 40 byte di mana XML setaranya — dengan tag pembuka, tag penutup, dan deklarasi XML-nya — mungkin memakan 150 byte atau lebih. JSON juga langsung memetakan ke struktur data native (objek, array, string, angka, boolean, null) di setiap bahasa pemrograman besar, menghilangkan impedance mismatch dari model DOM XML di mana semuanya adalah node. XML tetap menjadi pilihan tepat untuk format berpusat-dokumen seperti SVG, RSS, Atom, dan XHTML, untuk layanan SOAP di platform integrasi enterprise seperti MuleSoft, dan untuk sistem finansial serta pemerintahan legacy di mana skema XML diwajibkan secara kontraktual. Tapi untuk REST dan GraphQL API baru, JSON adalah ekspektasi dasar. JSON:API (jsonapi.org) adalah spesifikasi yang melangkah lebih jauh, mendefinisikan konvensi bagaimana JSON seharusnya distrukturkan dalam respons REST — termasuk objek resource dengan type dan id, peta relationships untuk resource terhubung, blok meta untuk pagination dan metadata, dan array errors yang distandardisasi. Tim mengadopsi JSON:API untuk menghindari diskusi berulang tentang apakah objek terkait harus disematkan inline atau direferensikan lewat ID, apakah error masuk ke array top-level atau sebagai properti, dan bagaimana cursor pagination seharusnya direpresentasikan.

JSON-RPC 2.0 adalah protokol remote procedure call yang dibangun di atas JSON. Sebuah request membawa nama method, array atau objek params, dan id; respons membawa result atau objek error berdampingan dengan id yang sama, memungkinkan pencocokan request-response melalui satu koneksi. Formatnya sengaja minimal: {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1} mengembalikan {"jsonrpc": "2.0", "result": 19, "id": 1}. JSON-RPC dipakai oleh Web3 API Ethereum untuk semua interaksi blockchain, oleh Language Server Protocol (LSP) yang menggerakkan intelijensi kode di VS Code, Neovim, dan setiap IDE modern, dan oleh berbagai sistem microservice internal di mana overhead verb HTTP dan URL routing tidak diperlukan. NDJSON (Newline-Delimited JSON, juga disebut JSON Lines) mengatasi batasan berbeda: streaming dataset besar yang tidak praktis dimuat sebagai satu array JSON. Dalam format NDJSON setiap baris adalah objek JSON yang independen dan lengkap. Server bisa mengeluarkan record secara bertahap saat dihasilkan tanpa menyangga seluruh dataset atau membungkusnya dalam array. Pipeline agregasi log, aliran event analitik, ekspor data pelatihan machine learning, dan endpoint API massal umum memakai NDJSON karena memungkinkan konsumen mulai memproses record pertama sebelum record terakhir dihasilkan.

Keempat format ini — REST JSON ad-hoc, JSON:API, JSON-RPC 2.0, dan NDJSON — masing-masing menyelesaikan masalah berbeda dan tidak bisa saling dipertukarkan. Memilih yang salah menciptakan friksi: server JSON-RPC yang dicoba dikonsumsi tim sebagai REST API akan punya semantik URL yang membingungkan; REST API ad-hoc yang mengembalikan array item dalam bentuk berbeda di endpoint berbeda mengarah ke overhead bikeshedding yang justru diciptakan JSON:API untuk dihilangkan; endpoint data streaming yang membungkus semuanya dalam satu array JSON memaksa konsumen menyangga seluruh respons sebelum mengurai satu record pun. Memahami di mana setiap format unggul membantu Anda memvalidasi dan men-debug payload API nyata dengan lebih efektif, karena struktur yang Anda harapkan sepenuhnya tergantung pada protokol mana yang menjadi dasar desain endpoint tersebut.

Keamanan JSON: injection, prototype pollution, dan pertimbangan CSRF

Injeksi JSON adalah salah satu kerentanan validasi input yang paling kurang dihargai dalam aplikasi web. Ia terjadi saat input yang dikontrol pengguna digabungkan langsung ke dalam string JSON memakai operasi string alih-alih serializer yang tepat. Endpoint yang membangun payload sebagai '{ "username": "' + userInput + '" }' langsung bisa dieksploitasi: pengguna yang memasukkan nilai ", "admin": true, "x": " keluar dari konteks string yang dimaksudkan dan menyuntikkan key tambahan sembarang ke objek JSON. Perbaikannya selalu memakai serializer JSON yang benar — JSON.stringify() di JavaScript, json.dumps() di Python, ObjectMapper Jackson di Java — dan tidak pernah membangun payload JSON lewat penggabungan string atau template literal. Formatter dan validator seperti ini berguna selama pengembangan untuk memeriksa persis apa yang dihasilkan serializer dan memastikan karakter khusus dalam nilai field di-escape dengan benar alih-alih ditafsirkan sebagai struktur JSON.

Prototype pollution adalah kelas serangan khusus untuk aplikasi JavaScript yang mengurai JSON dari sumber tidak tepercaya. Jika penyerang bisa menyebabkan aplikasi Anda memanggil JSON.parse() pada dokumen berisi {"__proto__": {"admin": true}} dan objek hasilnya kemudian digabungkan ke objek lain memakai fungsi deep-merge naif, key __proto__ bisa menulis ke prototype Object JavaScript itu sendiri — artinya setiap objek berikutnya dalam proses mewarisi admin: true seolah itu properti langsung. Ini sudah didemonstrasikan sebagai kerentanan yang bisa dieksploitasi di paket npm populer termasuk lodash (CVE-2019-10744), jQuery, dan lainnya. Mitigasi yang benar adalah memakai Object.create(null) sebagai target merge sehingga objek dasar tidak punya prototype, memvalidasi JSON yang masuk terhadap skema sebelum digabungkan, memakai fungsi reviver JSON.parse untuk menyaring key berbahaya, dan menghindari pola deep-merge pada data tidak tepercaya sama sekali.

Dua kerentanan historis lain patut diketahui sebagai konteks. JSON Hijacking adalah serangan yang berhasil sebelum model keamanan browser diperketat sekitar 2010: halaman jahat akan menyertakan tag <script src="https://victim-api.com/user-data"></script> yang menunjuk ke endpoint JSON terautentikasi, lalu menimpa konstruktor global Array untuk menangkap data yang diparsing saat dievaluasi. Browser modern memblokir eksekusi script cross-origin dari respons JSON, dan pertahanan standar mewajibkan Content-Type: application/json (yang tidak bisa diset oleh pengiriman form cross-origin) menghilangkan permukaan serangan ini. Konvensi Angular yang menambahkan prefiks )]}', pada respons JSON adalah sisa dari era ini — prefiks itu menyebabkan error sintaks jika respons dieksekusi sebagai script, membuatnya aman bahkan di browser lama. CSRF terhadap JSON API terkait: API JSON awal yang menerima Content-Type apa pun termasuk text/plain bisa dipicu oleh form HTML cross-origin, karena browser mengizinkan pengiriman form dengan content type itu. Mewajibkan Content-Type: application/json pada endpoint tulis — yang tidak bisa diset browser dalam pengiriman form cross-origin tanpa preflight CORS — menutup vektor ini. Digabungkan, kekhawatiran ini menegaskan prinsip yang berlaku sama pentingnya untuk tooling sisi klien maupun kode sisi server: jangan pernah percaya JSON dari sumber tidak tepercaya tanpa memvalidasi strukturnya dan menyanitasi kontennya sebelum memakainya dalam konteks apa pun yang relevan dengan keamanan.