Escape / Unescape JSON

JSON escape dan unescape online — gratis, privat, instan

Tool JSON escape ini mengubah teks apa pun menjadi string yang aman untuk JSON dan mengubah string yang di-escape kembali menjadi teks biasa — kedua arah dalam satu tempat, instan, dan sepenuhnya di browser Anda. Tempelkan konten Anda, pilih Escape atau Unescape, lalu salin hasilnya. Tidak ada yang perlu diinstal, tidak ada yang perlu didaftarkan. Karena setiap konversi berjalan lokal, data Anda tidak pernah meninggalkan perangkat — aman untuk payload API, access token, kata sandi, dan teks rahasia apa pun yang Anda tidak ingin unggah ke server.

Ini adalah cara tercepat untuk meng-escape sebuah string JSON untuk payload API, memasukkan potongan multi-baris ke file konfigurasi, atau memulihkan teks asli dari nilai yang di-escape yang Anda temukan di log. Konversi memakai mesin JSON native browser — bukan regex buatan tangan — sehingga hasilnya sama dengan yang dihasilkan JSON.stringify di JavaScript dan yang diharapkan oleh setiap parser yang sesuai spesifikasi di Python, Go, Java, dan Ruby.

Apa yang perlu di-escape dalam JSON — dan apa yang tidak

Hanya sekumpulan kecil karakter yang punya makna khusus di dalam string JSON. Tanda kutip ganda " harus menjadi \", backslash \ harus menjadi \\, dan karakter kontrol whitespace menjadi \b, \f, \n, \r dan \t. Karakter kontrol lain di bawah U+0020 ditulis sebagai escape \uXXXX. Selebihnya — huruf, angka, tanda kutip tunggal, hyphen, dan tanda baca biasa — dilewatkan tanpa disentuh. Ini sumber kebingungan yang umum: tanda kutip tunggal tidak perlu di-escape dalam JSON karena string JSON memakai tanda kutip ganda sebagai pembatas, bukan tanda kutip tunggal.

Salah menerapkan salah satu aturan ini adalah alasan JSON gagal diparsing. Tanda kutip ganda yang tidak di-escape mengakhiri string terlalu awal, menyebabkan error "Unexpected token". Backslash tunggal dibaca sebagai awal urutan escape — jika karakter berikutnya bukan karakter escape yang valid, parsing gagal. Newline literal di dalam string sama sekali tidak diperbolehkan oleh spesifikasi. Tempelkan nilai yang rusak itu ke mode Escape dan tool ini mengembalikan versi yang di-escape dengan benar dalam waktu kurang dari satu detik.

Escape, unescape, stringify — apa yang dilakukan tiap mode

Mode Escape mengkodekan teks Anda agar bisa berada di dalam string JSON. Secara default Anda mendapat isi yang sudah di-escape saja, siap ditempel di antara tanda kutip Anda sendiri; aktifkan Bungkus dalam kutip dan Anda mendapat nilai string JSON berkutip yang lengkap — persis seperti yang dihasilkan JSON.stringify(). Itulah perbedaan antara escaping (mengkodekan karakter khusus) dan stringifying (mengkodekan sekaligus membungkus dengan tanda kutip). Keduanya menghasilkan output yang diterima oleh setiap parser JSON standar.

Mode Unescape melakukan kebalikannya, menerjemahkan \", \\, \n, \t dan \uXXXX kembali menjadi karakter yang diwakilinya. Ia menerima input dengan atau tanpa tanda kutip di sekelilingnya dan melaporkan error yang jelas untuk escape yang cacat. Tombol Swap membalik output menjadi input di bawah mode yang berlawanan, sehingga round-trip hanya satu klik — escape sesuatu, verifikasi hasilnya, swap, dan pastikan Anda mendapat kembali teks aslinya.

Unicode, backslash, path Windows, dan output aman-HTML

JSON menyimpan Unicode sebagai UTF-8 mentah secara default, tapi terkadang Anda butuh ASCII murni. Aktifkan Escape non-ASCII (\uXXXX) dan setiap huruf beraksen atau emoji menjadi urutan \uXXXX — é menjadi \u00e9 dan 😀 menjadi surrogate pair \ud83d\ude00. Ini menjaga parser lama dan file konfigurasi khusus ASCII tetap berfungsi dengan benar tanpa kehilangan data.

Untuk path file Windows dan pola regex, penggandaan backslash berjalan otomatis: tempelkan C:\Users\me dan tool ini mengeluarkan C:\\Users\\me. Untuk penyisipan HTML, opsi Escape garis miring menulis ulang / menjadi \/ sehingga tag penutup script di dalam nilai string tidak bisa keluar dari HTML di sekelilingnya — tetap JSON valid yang diparsing identik, tapi aman disisipkan di halaman yang dirender server. Tool seperti JSONLint bisa memastikan output yang di-escape itu valid sebelum Anda men-deploy-nya.

Bagaimana perbandingannya dengan JSONLint, jsonformatter.org, VS Code, dan tool server-side

JSONLint memvalidasi apakah sebuah dokumen JSON lengkap terbentuk dengan benar. jsonformatter.org melakukan pretty-print JSON agar mudah dibaca. VS Code dengan formatter bawaannya menangani indentasi dan syntax highlighting tapi tidak meng-escape atau unescape nilai string individual. Tidak satu pun dari ini mengisi celah yang ditutup tool ini: memperbaiki satu string yang mengandung karakter khusus. Gunakan jsonformatter.org untuk memformat; JSONLint untuk memvalidasi; VS Code untuk bekerja dengan file lengkap Anda; tool ini untuk memperbaiki nilai string yang merusak parser.

Tool JSON escape server-side memang ada tapi punya trade-off: teks Anda meninggalkan perangkat. Jika Anda bekerja dengan API key, kata sandi, konfigurasi rahasia, atau data pengguna, mengirim itu ke server eksternal adalah risiko yang tidak perlu. Tool ini memproses semuanya di sisi klien — tidak ada yang diunggah, dicatat, atau disimpan. Ia bekerja offline setelah dimuat, sehingga Anda bisa memakainya tanpa koneksi jaringan apa pun. Tanpa akun untuk dibuat, tanpa batas rate, tanpa batas ukuran file.

Spesifikasi JSON: RFC 8259 dan aturan yang ditetapkannya

JSON diformalkan oleh Douglas Crockford pada awal 2000-an dan pertama kali dibakukan sebagai RFC 4627 pada 2006. Ia direvisi oleh RFC 7159 pada 2013 dan kemudian oleh RFC 8259 pada 2017, yang merupakan standar otoritatif saat ini. Spesifikasi ini mendefinisikan tepat enam tipe nilai: object (kumpulan pasangan key–value yang tidak berurutan), array (urutan berurutan), number, string, boolean (literal true dan false), dan null. Setiap parser JSON yang sesuai spesifikasi di setiap bahasa pemrograman dibangun di sekitar keenam tipe ini — tidak lebih, tidak kurang.

Aturan string JSON di bawah RFC 8259 tegas dan tidak bisa ditawar. String harus dibatasi oleh tanda kutip ganda — tanda kutip tunggal adalah error sintaks, bukan alternatif. Karakter kontrol di rentang U+0000 hingga U+001F — termasuk tab, newline, carriage return, dan backspace — tidak boleh muncul secara literal di dalam string; mereka harus direpresentasikan sebagai urutan escape. RFC 8259 menetapkan tepat tujuh urutan escape wajib: \" untuk tanda kutip ganda, \\ untuk backslash, \/ untuk garis miring (opsional tapi diperbolehkan), \b untuk backspace, \f untuk form feed, \n untuk newline, \r untuk carriage return, dan \t untuk tab. Kode poin Unicode apa pun juga bisa dikodekan sebagai \uXXXX memakai empat digit heksadesimal; karakter di luar Basic Multilingual Plane memakai surrogate pair UTF-16 yang ditulis sebagai dua urutan \uXXXX berturut-turut.

Satu klarifikasi penting dari RFC 8259: teks JSON yang dipertukarkan antar sistem yang bukan bagian dari ekosistem tertutup harus dikodekan dalam UTF-8. BOM (byte order mark, U+FEFF) tidak boleh muncul di awal teks JSON. Persyaratan ini menutup banyak ambiguitas historis seputar encoding karakter yang dulu menyebabkan masalah interoperabilitas di tahun-tahun antara RFC 4627 dan RFC 8259. Saat sebuah parser JSON melaporkan error encoding karakter alih-alih error parsing, biasanya ia sedang menolak input yang melanggar mandat UTF-8 ini.

JSON vs literal objek JavaScript: sintaks mirip, aturan berbeda

Kesalahpahaman paling umum tentang JSON adalah menganggapnya sama dengan JavaScript. Padahal tidak. JSON adalah format pertukaran data yang independen dari bahasa apa pun yang kebetulan berbagi sintaks permukaan dengan literal objek JavaScript — tapi keduanya punya perbedaan yang berarti. Dalam JSON, semua key dan semua nilai string harus memakai tanda kutip ganda. Literal objek JavaScript mengizinkan key tanpa kutip ({ foo: 1 }) dan string berkutip tunggal ('hello'); keduanya adalah error sintaks dalam JSON. JSON tidak mengizinkan koma berlebih setelah elemen terakhir dalam array atau objek — [1, 2, 3,] adalah JSON yang tidak valid meskipun mesin JavaScript modern menerimanya. JSON tidak mendukung komentar dalam bentuk apa pun, meskipun komentar adalah JavaScript yang sah. Ini sering menjebak developer yang mencoba memberi anotasi pada file konfigurasi dengan // atau /* */.

JSON juga tidak punya representasi untuk beberapa primitif JavaScript. Nilai undefined tidak ada dalam JSON — JSON.stringify() menghilangkan properti objek yang nilainya undefined alih-alih mensrialisasinya. Nilai numerik khusus Infinity, -Infinity, dan NaN tidak bisa direpresentasikan dalam JSON; JSON.stringify() mengubahnya menjadi null. Objek Date disrialisasi menjadi representasi string ISO 8601-nya (misalnya, "2024-01-15T09:30:00.000Z") — parser yang membacanya kembali menerima string, bukan Date, kecuali fungsi reviver merekonstruksi objek itu. Konversi diam-diam ini adalah sumber umum bug kehilangan data halus saat developer mengasumsikan JSON adalah format round-trip yang lossless untuk semua nilai JavaScript.

Kesenjangan antara sintaks JSON dan JavaScript inilah tepatnya yang membuat JSONC (JSON with Comments) diperkenalkan. VS Code memakai JSONC untuk settings.json, launch.json, tasks.json, dan tsconfig.json-nya, memproses awal untuk menghilangkan komentar sebelum mengurai sisanya sebagai JSON standar. JSONC bukan standar resmi — ia adalah ekstensi pragmatis untuk file konfigurasi yang diedit manusia di mana kemampuan memberi anotasi lebih penting daripada interoperabilitas ketat.

JSON5, HJSON, TOML, dan YAML: saat JSON tidak cukup

Ketegasan yang membuat JSON ideal untuk pertukaran data mesin-ke-mesin membuatnya melelahkan untuk file konfigurasi yang ditulis manusia. Beberapa format muncul untuk mengatasi ini. JSON5 (2012) adalah ekstensi paling konservatif: ia menambahkan string berkutip tunggal, key objek tanpa kutip, koma berlebih, komentar gaya-C (// dan /* */), literal angka heksadesimal (0xFF), dan string multi-baris memakai kelanjutan backslash. JSON5 adalah superset dari JSON — semua JSON valid adalah JSON5 valid — dan dipakai di beberapa file konfigurasi Babel dan ESLint. HJSON (Human JSON) melangkah lebih jauh, menambahkan string multi-baris tanpa urutan escape dan komentar gaya-hash, dan dipakai di beberapa ekosistem tooling CLI.

TOML (Tom's Obvious Minimal Language) memakai pendekatan yang sama sekali berbeda, memakai sintaks mirip-INI yang sama sekali tidak berhubungan dengan JSON. TOML unggul dalam konfigurasi hierarkis dan menjadi format di balik Cargo.toml Rust dan pyproject.toml Python. YAML menempati posisi berbeda: YAML 1.2 adalah superset dari JSON, artinya setiap dokumen JSON valid adalah YAML valid, tapi YAML memperluas JSON dengan anchor, alias, block scalar, dan type tag. YAML banyak dipakai dalam pipeline CI/CD (GitHub Actions, GitLab CI) dan manifest Kubernetes. Trade-off di semua format ini konsisten: JSON adalah format paling sederhana untuk diparsing dengan benar — grammar-nya muat dalam satu halaman — inilah sebabnya ia mendominasi API dan pertukaran data, sementara TOML dan YAML unggul untuk file konfigurasi yang ditulis dan dipelihara manusia.

Untuk keperluan escaping, hanya JSON itu sendiri yang penting — JSON5, HJSON, TOML, dan YAML semuanya punya aturan escaping string sendiri yang sebagian tumpang tindih dengan JSON tapi berbeda dalam hal-hal penting. String yang di-escape dengan benar untuk JSON akan diparsing dengan benar di parser JSON5 mana pun, tapi kebalikannya tidak berlaku. Saat membangun API, pipeline log, atau komunikasi antar-layanan, selalu targetkan JSON ketat (RFC 8259) alih-alih format superset apa pun, dan gunakan tool atau fungsi library untuk menangani escaping alih-alih melakukannya secara manual.

Parsing dan serialisasi JSON: JavaScript, Python, dan jebakan presisi integer

Setiap bahasa besar menyediakan library JSON. Di JavaScript, JSON.stringify(value, replacer, space) mensrialisasi sebuah nilai menjadi string JSON. Argumen opsional replacer adalah array nama properti untuk disertakan atau fungsi yang bisa mentransformasi nilai selama serialisasi — berguna untuk menyaring field sensitif atau mengonversi tipe yang tidak bisa disrialisasi. Argumen space mengatur pretty-printing: masukkan angka untuk sejumlah spasi indentasi, atau string (umumnya "\t") untuk memakai tab. JSON.parse(text, reviver) mengurai string JSON kembali menjadi nilai JavaScript. Fungsi opsional reviver menerima setiap pasangan key–value selama parsing dan bisa mentransformasi nilai — kasus penggunaan umum adalah merekonstruksi objek Date dari string ISO 8601. Di Python, fungsi setaranya adalah json.dumps() dan json.loads(). json.dumps() menerima indent untuk pretty-printing, ensure_ascii=False agar karakter non-ASCII muncul apa adanya alih-alih sebagai escape \uXXXX, dan fungsi default untuk mensrialisasi tipe kustom yang tidak diketahui library.

Edge case terkenal yang mengejutkan sistem produksi besar adalah masalah presisi integer. Spesifikasi JSON tidak menetapkan batas atas untuk ukuran angka, tapi JavaScript merepresentasikan semua angka sebagai nilai floating-point presisi ganda IEEE 754, yang hanya bisa merepresentasikan integer secara tepat hingga 2⁵³ − 1 (9.007.199.254.740.991). Di atas batas itu, integer berurutan memetakan ke float yang sama dan menjadi tidak bisa dibedakan. ID tweet Twitter melampaui ambang ini seiring platform tumbuh, menyebabkan klien JavaScript diam-diam merusak ID saat mengurai respons API — tweet dengan satu ID diperlakukan sebagai tweet berbeda. Perbaikan Twitter adalah mengirim id_str (representasi string) berdampingan dengan field numerik id. JavaScript modern mengatasi ini dengan BigInt, tapi JSON.parse() masih belum menangani integer besar sebagai BigInt secara otomatis — solusinya termasuk memakai reviver kustom atau library pihak ketiga seperti json-bigint.

JSON Schema (saat ini di draft 2020-12) memperluas JSON dengan lapisan meta untuk memvalidasi struktur dokumen. Sebuah dokumen JSON Schema menentukan batasan tipe, field wajib, rentang numerik, pola string, dan nilai enum yang diizinkan memakai JSON itu sendiri sebagai bahasa skema. OpenAPI/Swagger memakai JSON Schema untuk mendefinisikan bentuk body request dan response API. Validator JavaScript yang paling banyak dipakai adalah ajv (Another JSON Validator), yang menggerakkan tool mulai dari webpack hingga ESLint. Di dalam sebuah skema, $ref memungkinkan penggunaan kembali definisi umum, sementara oneOf, anyOf, dan allOf memodelkan tipe union dan intersection. Validasi JSON Schema adalah validasi runtime — ia menangkap error bentuk data di payload produksi. Type checking TypeScript adalah validasi compile-time — ia menangkap error bentuk di kode sumber. Keduanya saling melengkapi: tipe TypeScript menjaga kode Anda benar; JSON Schema menjaga data API yang masuk tetap benar.