Kenapa HTML Email Berbeda dari HTML Website?

Aplikasi email pada dasarnya adalah “viewer” yang ketat. Mereka memprioritaskan keamanan dan kenyamanan pengguna. Karena itu, email sering dirender dengan mesin yang berbeda-beda, aturan sanitasi yang ketat, serta kebijakan pemblokiran konten aktif. Hasilnya, markup yang sama bisa tampil berbeda di tiap tempat.

Selain itu, banyak klien email ingin mencegah pelacakan agresif, phishing, dan serangan berbasis skrip. Maka, mereka membatasi apa yang boleh berjalan di dalam email. Inilah alasan kenapa HTML email sering terasa seperti kembali ke era layout tabel, padding manual, dan CSS yang “aman-aman saja”.

Aturan Emas: JavaScript dan Konten Aktif Hampir Selalu Diblokir

Kalau kamu berharap bisa menaruh JavaScript untuk animasi, validasi form, atau tombol interaktif, hampir pasti itu tidak akan bekerja. Mayoritas klien email memblokir <script>, event handler seperti onclick, serta konten aktif lain demi keamanan.

Bahkan elemen seperti form dan input sering dibatasi atau tidak didukung. Karena itu, pendekatan yang umum adalah menjadikan email sebagai “presentasi” yang mendorong pengguna kembali ke web atau aplikasi, misalnya lewat tombol CTA yang mengarah ke halaman aman.

Dukungan CSS Tidak Konsisten: Ini Sumber Kekacauan Nomor Satu

Di web, kita mengandalkan CSS modern: flexbox, grid, positioning kompleks, dan selector yang rapi. Di email, dukungan CSS sangat tidak konsisten. Ada klien yang cukup modern, ada yang sangat konservatif. Bahkan dalam satu ekosistem, perilaku bisa berbeda antara aplikasi mobile dan web.

Inline CSS biasanya paling aman

Banyak klien email lebih “ramah” pada style inline ketimbang CSS di <style>. Beberapa akan memindahkan, memodifikasi, atau memotong CSS internal. Karena itu, praktik umum adalah menggunakan inline style untuk properti penting seperti font, warna, padding, dan alignment.

Flexbox/Grid sering tidak bisa diandalkan

Layout modern bisa bekerja di sebagian klien, tetapi gagal total di klien lain. Kalau targetmu lintas klien, pendekatan paling stabil masih mengandalkan tabel untuk struktur layout utama. Kedengarannya kuno, tapi di email, tabel adalah “lingua franca” yang paling konsisten.

Margin bisa bermasalah, padding lebih aman

Banyak masalah spacing di email datang dari margin yang diabaikan atau dihitung berbeda. Padding pada sel tabel atau wrapper sering lebih stabil. Kalau butuh jarak vertikal, sering kali lebih aman menaruh spacer berbasis padding atau baris tabel khusus.

Gambar: Bisa Tidak Muncul, Bisa Berubah Ukuran, Bisa Terlihat “Aneh”

Gambar adalah elemen yang sering bikin email terasa hidup, tapi juga yang paling sering kena kebijakan keamanan. Banyak klien email memblokir gambar secara default sampai pengguna menekan “Download images”. Karena itu, jangan pernah mengandalkan gambar sebagai satu-satunya pembawa informasi.

Selalu sediakan alt text yang bermakna

Kalau gambar tidak dimuat, alt yang jelas akan menyelamatkan pesanmu. Hindari alt text yang sekadar “image” atau “banner”. Buat alt text yang menjelaskan fungsi gambar, terutama kalau itu tombol atau informasi penting.

Gunakan ukuran eksplisit

Menetapkan width dan height membantu mengurangi layout shift. Banyak klien email lebih stabil saat ukuran gambar ditentukan. Untuk responsif, kamu bisa pakai teknik sederhana: gambar dengan max-width:100% dan wrapper yang terkontrol.

Hindari gambar sebagai tombol utama tanpa fallback

Tombol CTA sebaiknya berupa elemen yang tetap terbaca meski gambar tidak tampil. Tombol berbasis tabel dengan background color dan teks adalah pendekatan klasik yang masih sangat efektif.

Font dan Tipografi: Jangan Mengandalkan Font “Keren”

Web font tidak selalu didukung. Walaupun beberapa klien bisa menampilkan font khusus, banyak yang akan jatuh ke font default sistem. Karena itu, gunakan font stack yang masuk akal: pilih font utama lalu siapkan fallback seperti Arial, Helvetica, atau system font setara.

Selain font, perhatikan line-height dan ukuran teks. Email sering dibaca di layar kecil, jadi tipografi yang terlalu rapat akan terasa melelahkan. Lebih baik pakai ukuran teks yang nyaman, line-height cukup longgar, dan paragraf pendek.

Dark Mode: Warna Bisa “Diubah Paksa” oleh Klien Email

Dark mode bukan sekadar membalik background. Beberapa klien email menerapkan transformasi warna otomatis. Akibatnya, teks yang tadinya kontras bisa jadi pudar, logo bisa terlihat aneh, atau background menjadi abu-abu yang tidak kamu rencanakan.

Cara paling praktis untuk mengurangi risiko adalah: menjaga kontras yang kuat, menghindari teks tipis dengan warna abu-abu muda, dan memastikan elemen penting tetap terbaca. Untuk logo, versi dengan background transparan kadang justru membuat logo “hilang” di dark mode, jadi pertimbangkan varian logo yang aman.

Link, Tracking, dan Keamanan: Jangan Bikin Klien Curiga

Banyak platform email dan filter keamanan memeriksa link dan pola konten. Kalau emailmu terlihat seperti phishing, deliverability bisa turun atau email masuk spam. Hal-hal kecil bisa berpengaruh, misalnya: terlalu banyak link, anchor text yang tidak sesuai tujuan, atau domain yang tampak tidak konsisten.

Pastikan link terlihat masuk akal, gunakan teks yang jelas, dan hindari trik yang membuat link “menyamar”. Untuk email verifikasi, buat CTA yang tegas dan sertakan link mentah sebagai alternatif (fallback) jika tombol tidak bisa diklik.

Struktur Layout yang Paling Stabil: Sederhana, Berlapis, dan Berbasis Tabel

Kalau targetmu adalah konsistensi lintas klien, desain sederhana biasanya menang. Struktur yang sering dipakai: satu kontainer utama, satu kolom, lebar yang aman, dan komponen yang jelas. Alih-alih layout kompleks, gunakan blok-blok konten yang ditumpuk vertikal.

Tabel dipakai untuk “membangun” struktur: header, body, footer, serta tombol CTA. Dengan cara ini, kamu mengurangi kejutan render dan membuat email lebih mudah diprediksi. Bahkan untuk spacing, tabel dan padding sering lebih stabil dibanding margin modern.

Masalah Populer: Email Terpotong, CSS Hilang, atau Tampilan Berantakan

Email “terpotong” atau konten menghilang

Beberapa klien email membatasi ukuran email atau memotong konten yang dianggap terlalu panjang/berat. Konten yang terlalu banyak gambar besar atau markup berlebihan dapat memperbesar risiko pemotongan. Karena itu, kompres gambar, minimalkan markup yang tidak perlu, dan fokus pada pesan inti.

CSS hilang setelah dikirim

Ini terjadi saat klien memodifikasi <style> atau saat platform pengirim tidak meng-inline CSS. Kalau kamu mengandalkan CSS internal, pastikan itu tidak dibersihkan oleh sanitasi, dan pertimbangkan inline untuk properti krusial seperti warna, font, dan padding.

Spacing tidak konsisten

Ini sering karena margin yang diabaikan, terutama pada elemen block tertentu. Cara klasik yang sering berhasil adalah menggunakan wrapper tabel dan padding yang eksplisit. Untuk jarak vertikal, gunakan spacer yang jelas daripada berharap margin bekerja seragam.

Checklist Praktis: HTML Email yang Lebih “Tahan Banting”

• Gunakan struktur sederhana dengan kontainer utama dan blok konten vertikal.
• Inline style untuk hal penting seperti font, warna, padding, alignment.
• Hindari JavaScript dan elemen interaktif yang bergantung pada skrip.
• Gunakan tabel untuk layout jika kamu butuh kompatibilitas luas.
• Set ukuran gambar dan gunakan alt text yang informatif.
• Pastikan kontras aman terutama untuk dark mode dan layar kecil.
• CTA jelas dan sediakan link alternatif jika tombol gagal.
• Uji di beberapa klien sebelum mengirim ke banyak orang.

Penutup: Anggap HTML Email Sebagai Format yang Berbeda

Kunci sukses di HTML email adalah menerima kenyataan bahwa ini bukan web. Bukan berarti kamu tidak bisa membuat email yang cantik dan profesional, tapi kamu perlu bermain di aturan yang lebih ketat. Dengan struktur sederhana, penggunaan tabel yang tepat, style yang aman, dan perhatian pada gambar serta dark mode, emailmu bisa terlihat rapi di lebih banyak tempat.

Setelah kamu paham batasannya, proses desain jadi lebih cepat: kamu tahu mana yang aman, mana yang berisiko, dan bagaimana menulis email yang tetap enak dibaca meski klien email melakukan “interpretasi” sendiri.