Enkode / Dekode Entitas HTML

Encode dan decode entitas HTML online

Alat entitas HTML ini menggabungkan tiga fungsi dalam satu tempat: meng-encode teks menjadi entitas HTML, men-decode entitas kembali menjadi teks yang mudah dibaca, dan memberikan daftar entitas HTML yang bisa dicari dan disalin. Ketik atau tempel di panel kiri dan hasil konversinya langsung muncul di kanan — beralih antara encode dan decode, tukar kedua panel, dan salin hasilnya dengan satu klik.

Semua berjalan lokal di browser Anda, sehingga teks yang Anda konversi tidak pernah diunggah ke server mana pun. Tidak ada yang perlu diinstal, tidak ada akun untuk dibuat, dan tidak ada batas penggunaan. Muat ulang halaman saat offline dan tetap berfungsi — karena tidak ada panggilan server yang terjadi di titik mana pun.

Apa itu entitas HTML dan mengapa penting

Entitas HTML adalah kode singkat yang mewakili sebuah karakter. Selalu dimulai dengan ampersand dan diakhiri titik koma — misalnya & mewakili tanda ampersand dan   mewakili spasi non-breaking. Entitas ada karena dua alasan. Pertama, beberapa karakter tereservasi dalam HTML: <, >, atau & mentah bisa dibaca sebagai markup dan merusak halaman Anda, sehingga ditulis sebagai <, >, dan & sebagai gantinya.

Kedua, entitas memungkinkan Anda menyertakan karakter khusus — aksen, tanda mata uang, simbol matematika, dan panah — yang mungkin sulit diketik atau tidak bertahan saat encoding teks berubah. Meng-escape karakter tereservasi adalah tepat yang mencegah < yang tersasar merusak tata letak atau potongan input pengguna berubah menjadi tag yang tidak diinginkan. Ini fundamental bagi keamanan web dan alasan mengapa membersihkan input pengguna selalu melibatkan encoding entitas HTML.

Entitas nama, desimal, dan heksadesimal

Setiap karakter bisa ditulis tiga cara. Entitas nama memakai kata kunci yang mudah dibaca — © untuk tanda hak cipta ©. Entitas desimal numerik memakai kode Unicode karakter dalam basis 10 — ©. Entitas heksadesimal memakai basis 16 — ©. Ketiganya menghasilkan © yang sama.

Entitas nama paling mudah dibaca, tapi hanya sekitar 2.200 karakter yang punya nama HTML5. HTML4 hanya mendefinisikan sekitar 255. Standar referensi karakter bernama HTML5 yang diperluas menambahkan ratusan lagi — operator matematika, panah, dan simbol tipografi yang sebelumnya tidak tersedia. Entitas numerik (desimal atau hex) mencakup setiap karakter Unicode, termasuk semua emoji. Saat meng-encode, pilih bentuk keluaran yang sesuai konteks Anda: nama untuk keterbacaan di kode sumber, desimal atau hex saat Anda butuh kode yang terjamin untuk karakter apa pun.

Daftar entitas HTML yang bisa dicari — panah, simbol, dan lainnya

Di bawah konverter ada daftar entitas HTML lengkap yang dikelompokkan, mencakup tanda baca, panah, mata uang, matematika, dan huruf Yunani. Cari berdasarkan nama, simbol, atau angka — ketik 'arrow' untuk menemukan → (→), 'euro' untuk € (€), atau '38' untuk ampersand — lalu klik sel mana pun untuk menyalin simbolnya, entitas namanya, kode desimalnya, atau kode heksnya.

Ini cara tercepat untuk mengambil kode karakter HTML yang tepat tanpa menghafalnya atau mencari di halaman referensi statis. Daftar ini mencakup standar referensi karakter bernama HTML5 lengkap — lebih dari 2.200 entri — jauh lebih banyak daripada sekitar 255 entitas di W3Schools atau tabel parsial khusus HTML4 di FreeFormatter. Jika Anda sering bekerja dengan notasi matematika, simbol tipografi, atau karakter Latin yang diperluas, daftar ini mencakup semuanya.

Bagaimana ini dibandingkan dengan FreeFormatter, W3Schools, dan MDN

Kebanyakan sumber daya entitas HTML adalah halaman referensi statis. W3Schools, referensi karakter MDN, dan FreeFormatter.com semuanya mencantumkan entitas yang bisa Anda cari secara manual. Tidak satu pun dari mereka memungkinkan Anda menempel blok teks dan meng-encode atau men-decode seluruhnya sekaligus. Encoder entitas FreeFormatter adalah alternatif terdekat, tapi mengirim teks Anda ke server mereka untuk diproses, memerlukan submit formulir dan reload halaman, dan hanya mencakup entitas HTML4.

Alat ini melakukan semuanya di satu halaman, secara instan, sepenuhnya di sisi klien: encode satu paragraf teks, alihkan ke decode, lalu cari daftar entitas — semuanya di tab yang sama tanpa round-trip. Alat ini juga mencakup set lengkap referensi karakter bernama HTML5, bukan hanya HTML4, yang penting saat bekerja dengan konten modern yang menyertakan simbol tipografi, panah, atau notasi matematika. Dan karena semuanya berjalan lokal, Anda bisa meng-encode konten privat — dokumen internal, template email, salinan yang belum dirilis — tanpa itu pernah sampai ke server pihak ketiga.

Privat, instan, dan gratis — juga bekerja offline

Setiap konversi — encoding, decoding, atau menyalin dari daftar entitas — terjadi lokal di browser Anda memakai JavaScript, sehingga bahkan markup rahasia pun tidak pernah meninggalkan perangkat Anda. Tidak ada server, tidak ada login, dan tidak ada batas rate. Alat ini bekerja sama baik apakah Anda punya koneksi cepat, koneksi lambat, atau tidak ada koneksi sama sekali setelah pemuatan halaman awal.

Bandingkan dengan alat seperti FreeFormatter.com atau validator HTML online yang memerlukan permintaan jaringan untuk setiap konversi. Bagi developer yang mengerjakan proyek klien atau tooling internal, menjalankan encoding secara lokal berarti markup Anda tidak pernah menyentuh server pihak ketiga. Simpan ini sebagai bookmark konverter entitas HTML dan referensi andalan Anda — untuk meng-escape HTML, mencari kode karakter, atau men-decode markup yang di-encode dari file sumber atau dump database.

Sejarah entitas HTML: dari SGML ke HTML5

HTML awalnya berasal dari SGML (Standard Generalized Markup Language), meta-bahasa dokumen yang distandarkan dalam ISO 8879:1986. SGML mendefinisikan sistem referensi entitas karakter sejak awal, dan HTML mewarisinya secara langsung. Alasan entitas benar-benar diperlukan berakar pada batasan mendasar dari web awal: dokumen sumber HTML harus terdiri dari karakter ASCII yang bisa dicetak. Jika penulis butuh menampilkan karakter < secara literal di halaman, parser HTML akan membacanya sebagai awal sebuah tag — sehingga kode pengganti diperlukan. Entitas bernama seperti < dan & menyelesaikan masalah itu dengan memberi penulis cara menulis karakter tereservasi di sumber tanpa memicu perilaku parser.

Entitas HTML terbagi dalam tiga kategori. Entitas bernama memakai kata kunci yang mudah dibaca manusia di antara ampersand dan titik koma — &, <, >, ", '. Referensi numerik desimal memakai kode Unicode karakter dalam basis 10, seperti < untuk <. Referensi numerik heksadesimal memakai basis 16, seperti < untuk karakter yang sama. Ketiganya menghasilkan keluaran render yang identik. Entitas bernama lebih mudah dibaca tapi hanya ada untuk sebagian Unicode; referensi numerik mencakup setiap titik kode tanpa terkecuali, termasuk semua emoji dan karakter bidang tambahan (supplementary plane).

Kesenjangan antara penanganan entitas XML dan HTML patut dipahami. XML hanya mendefinisikan lima entitas bawaan — &, <, >, ", dan ' — dan entitas bernama lainnya harus dideklarasikan secara eksplisit dalam DTD sebelum bisa dipakai. HTML, sebaliknya, punya ratusan entitas bernama bawaan yang didefinisikan langsung dalam spesifikasi: HTML4 menstandarkan sekitar 255, dan HTML5 memperluasnya menjadi lebih dari 2.200 referensi karakter bernama, mencakup operator matematika, panah, simbol tipografi, dan karakter Latin yang diperluas yang tidak tersedia di versi standar sebelumnya.

Unicode, UTF-8, dan entitas mana yang benar-benar masih Anda butuhkan

Saat sistem entitas HTML dirancang, ASCII adalah encoding yang dominan. Untuk menyertakan karakter di luar rentang 128-karakter ASCII — tanda hak cipta, simbol Euro, huruf Yunani — Anda perlu entitas bernama atau referensi numerik, karena byte yang mendasarinya tidak punya interpretasi yang andal di berbagai sistem dan lokal. Kemunculan Unicode dan, yang lebih penting, adopsi UTF-8 yang hampir universal sebagai encoding web mengubah seluruh perhitungan ini. UTF-8 bisa merepresentasikan setiap satu dari 1,1 juta titik kode Unicode sebagai urutan byte, dan hampir semua server web, browser, database, dan editor teks modern menanganinya secara native.

Di halaman UTF-8 — dideklarasikan dengan <meta charset="UTF-8"> di head dokumen — Anda bisa menyematkan karakter Unicode apa pun langsung di sumber HTML. Simbol hak cipta ©, tanda merek dagang ™, tanda Euro €, simbol tak hingga ∞, dan tanda lebih-besar-sama-dengan ≥ semuanya bisa muncul sebagai karakter literal tanpa encoding apa pun. Browser membaca deklarasi charset, memakainya untuk menafsirkan byte yang diterimanya, dan merender karakternya dengan benar. Ini berarti sebagian besar entitas yang biasa dipakai orang — ©, ™, €, ∞ — sepenuhnya opsional di halaman UTF-8 modern; karakter literal lebih disukai untuk keterbacaan dan kemudahan pemeliharaan.

Hanya lima karakter yang benar-benar memerlukan encoding dalam HTML, dan hanya dalam konteks tertentu: ampersand & (sebagai &) di teks dan nilai atribut, tanda kurang-dari < (sebagai <) di konten teks, tanda lebih-dari > (sebagai >) di konten teks, tanda kutip ganda " (sebagai ") di dalam nilai atribut berkutip ganda, dan tanda kutip tunggal ' (sebagai ' atau ') di dalam nilai atribut berkutip tunggal. Sisanya opsional. Halaman yang padat dengan   dan entitas bernama untuk setiap karakter beraksen lebih sulit dibaca dan diedit dibanding halaman dengan UTF-8 literal — beban pemeliharaan HTML yang terlalu banyak di-encode itu nyata, dan tooling modern tidak memberi keuntungan apa pun untuk itu.

Escaping HTML dan XSS: mengapa encoding yang benar adalah kebutuhan keamanan

Cross-Site Scripting (XSS) secara konsisten masuk peringkat OWASP Top 10 kerentanan aplikasi web paling kritis. Serangan XSS terjadi ketika input yang dipasok pengguna dirender sebagai HTML tanpa escaping yang benar. Payload injeksi klasik terlihat seperti <script>alert(document.cookie)</script>. Jika string itu disimpan dalam database dan kemudian dikeluarkan langsung ke halaman HTML tanpa escaping, browser mengeksekusinya sebagai skrip — berpotensi mencuri cookie sesi, mengalihkan pengguna, atau melakukan aksi atas nama mereka. Pertahanannya adalah encoding entitas HTML yang benar di titik output: < yang sama yang merusak tata letak jika tidak di-encode menjadi teks literal < yang tidak berbahaya setelah di-escape, dan browser tidak pernah menafsirkannya sebagai markup.

Nuansa kritisnya adalah konteks rendering berbeda memerlukan strategi escaping berbeda. Dalam konteks teks HTML (di antara tag), encode <, >, dan &. Dalam konteks nilai atribut HTML, encode juga karakter kutip di sekitarnya — " atau ' — jika tidak, penyerang bisa menutup atribut dan menyuntikkan atribut baru seperti onmouseover. Dalam konteks string JavaScript (di dalam blok <script>), encoding entitas HTML tidak cukup — Anda butuh escaping string JavaScript (urutan \uXXXX) atau JSON.stringify, karena mesin JavaScript memproses string sebelum parser HTML melakukannya. Dalam konteks URL (di dalam href atau src), escaping yang benar adalah percent-encoding (%20 untuk spasi), bukan entitas HTML — mencampur keduanya adalah sumber umum tautan rusak dan titik injeksi yang belum diperbaiki.

OWASP XSS Prevention Cheat Sheet adalah referensi otoritatif untuk aturan spesifik-konteks ini. Kesimpulan praktis bagi kebanyakan developer adalah mengandalkan framework atau template engine yang meng-auto-escape secara default — bahasa template Django mengonversi {{ variable }} menjadi output aman-HTML secara otomatis dan memerlukan {{ variable|safe }} eksplisit untuk meloloskan HTML mentah; Jinja2 berperilaku sama; JSX React meng-escape semua nilai string sebelum merendernya ke DOM. Memahami apa yang dilakukan framework Anda secara default, dan kapan ia tidak meng-escape, adalah satu hal terpenting yang bisa Anda ketahui tentang pencegahan XSS. Encoding entitas manual dengan alat seperti ini berharga saat Anda bekerja di luar framework — menulis template HTML mentah, menghasilkan markup dalam skrip build, atau membangun string HTML di JavaScript.

Entitas HTML dalam email, template engine, dan feed XML

Email HTML adalah konteks di mana encoding entitas tetap paling penting bahkan di 2024. Klien email memakai beragam mesin rendering — Gmail membersihkan dan me-render ulang HTML lewat sanitizer-nya sendiri, Outlook di Windows memakai mesin rendering Word (bukan browser), Apple Mail memakai WebKit — dan dukungan UTF-8 serta penanganan karakter mereka bervariasi cukup besar. Menulis — alih-alih em dash literal, atau © alih-alih ©, memastikan karakternya tampil benar di klien yang mungkin salah menafsirkan atau membuang byte titik-kode tinggi. Mesin rendering Outlook khususnya punya masalah yang diketahui dengan karakter Unicode tertentu dan jauh lebih toleran terhadap entitas bernama, itulah sebabnya HTML email yang dibuat secara profesional cenderung memakai markup padat entitas yang dianggap tidak perlu di halaman web.

Editor teks kaya seperti CKEditor dan TinyMCE sering menghasilkan output HTML padat entitas secara default, meng-encode karakter yang sebenarnya akan tampil baik sebagai UTF-8 literal di browser modern. Ini perilaku warisan dari era ketika asumsi encoding tidak bisa dipercaya. Beberapa sistem manajemen konten menyimpan HTML yang sudah di-encode entitas ini di database dan kemudian mengeluarkannya lewat lapisan template yang juga meng-auto-escape — menghasilkan double-encoding, di mana pengguna mengetik ampersand, editor menulis &, CMS menyimpannya, dan template engine kemudian meng-escape-nya lagi menjadi &, yang dilihat pengguna di halaman. Mengenali double-encoding cukup mudah: tempel output yang terlihat ke panel Decode di sini dan decode sekali — jika hasilnya masih berisi kode entitas alih-alih karakter polos, decode lagi. Solusinya adalah menandai nilai tersebut sebagai sudah di-escape di lapisan template, bukan men-decode-nya saat dibaca.

Saat HTML disematkan di dalam dokumen XML — feed RSS dan Atom, file SVG, XHTML yang disajikan sebagai application/xhtml+xml — parser XML menerapkan aturan yang lebih ketat daripada parser HTML. XML hanya mengenali lima entitas bawaan dan memperlakukan entitas bernama yang tidak dikenal sebagai kesalahan parse fatal. Jika feed Atom Anda berisi — tanpa deklarasi DTD, parser XML yang sesuai standar akan menolak seluruh dokumen. Pendekatan yang benar adalah memakai entitas numerik (— untuk em dash) yang diterima parser XML secara universal, atau menyertakan karakter UTF-8 literal secara langsung, karena XML memerlukan UTF-8 atau UTF-16 dan keduanya menangani seluruh rentang Unicode. Perbedaan ini paling penting saat menghasilkan XML feed secara terprogram: mengganti karakter dengan entitas HTML bernama lewat string-replace adalah kesalahan umum yang merusak validator dan agregator feed.