Jawaban 10 detik: cara mengonversi pixel ke rem dan px ke em
Jika Anda bertanya bagaimana cara mengonversi pixel ke rem, rumusnya sederhana: bagi nilai pixel Anda dengan ukuran font akar, yaitu 16px di sebagian besar browser secara default. Jadi 24px dalam rem adalah 24 ÷ 16 = 1.5rem. Itu langsung menjawab pencarian umum “Berapa 24 px dalam rem?”
Untuk bagaimana cara mengonversi px ke em, perhitungannya sama tetapi penyebutnya berubah: Anda membagi dengan ukuran font terkomputasi dari elemen induk, bukan akar. Jika induknya 16px, 1em sama dengan 16px; tetapi jika induknya 20px, 1em sama dengan 20px. Itulah mengapa pertanyaan “Berapa px 1 em?” tidak memiliki jawaban tunggal—itu bergantung pada konteks.
Dalam praktiknya, saya menggunakan aturan sederhana: rem bersifat global (relatif terhadap akar), em bersifat lokal (relatif terhadap induk). Basis default 16px hanya berlaku jika pengguna atau stylesheet tidak mengubahnya. Jika Anda ingin melewati perhitungan manual, Konverter Pixel ke EM/REM kami default ke 16px dan mengonversi kedua arah secara instan, tetapi ingat bahwa ia tidak dapat mengetahui ukuran induk bersarang Anda.
Mengapa saya berhenti mempercayai kalkulator px-ke-rem universal setelah dashboard rusak
Ketika saya pertama kali membangun dashboard analitik SaaS pada 2021 menggunakan React, styled-components, dan Storybook, saya naif menjalankan setiap nilai pixel Figma melalui kalkulator bookmarklet yang diatur ke 16px. Itu berhasil untuk kartu tingkat atas. Lalu saya menyarangkan tooltip di dalam sidebar yang memiliki ukuran font sendiri 14px. Tiba-tiba, padding “1.5rem” saya dirender pada 21px di dalam tooltip alih-alih 24px, dan tata letaknya tumpang tindih.
Kesalahannya bukan pada kalkulator—tetapi pada asumsi bahwa em dan rem berperilaku identik. Alat yang saya gunakan hanya menghasilkan rem, tetapi saya secara manual mengganti beberapa nilai ke em untuk “fleksibilitas”. Kebanyakan orang tidak menyadari bahwa konverter px-ke-rem diam-diam mengabaikan pewarisan, yang justru menjadi inti dari em. Setelah debugging selama dua jam dengan snapshot visual Chromatic, saya mengadopsi kebijakan unit yang ketat dan strategi penskalaan akar yang akan saya bagikan di bawah ini.
Pengalaman ini mengajarkan saya bahwa konversi bukan sekadar aritmetika; ini adalah keputusan arsitektural. Pixel bersifat absolut, tetapi em dan rem bersifat cairan secara desain. Hal yang tidak diberitahukan orang tentang unit relatif CSS adalah bahwa mereka berlipat ganda melalui pohon DOM, dan perkalian itu bisa menjadi sahabat terbaik Anda atau mimpi buruk terburuk Anda.
Em vs rem: perbedaan kritis yang merusak komponen bersarang
Artikel pesaing semua mendefinisikan em sebagai “relatif terhadap ukuran font induknya” dan rem sebagai “relatif terhadap akar”. Benar, tetapi mereka jarang menunjukkan efek penggandaan. Mari kita lihat skenario nyata dari sistem desain fintech yang saya kelola.
Bagaimana em menggabungkan efek dalam komponen bersarang
Bayangkan sebuah kartu dengan font-size: 1.25rem (20px pada akar 16px). Di dalamnya, paragraf diatur ke font-size: 0.9em menghitung menjadi 18px. Di dalam paragraf itu, span dengan font-size: 0.8em menjadi 14.4px. Jika Anda kemudian mengubah ukuran font akar kartu untuk responsivitas, rantai em diskalakan tidak terduga karena setiap langkah merujuk pada yang sebelumnya.
Dalam proyek yang saya audit untuk klien fintech, tombol menggunakan padding: 0.5em di dalam wadah yang telah diskalakan ke 22px untuk tablet. Padding tombol membengkak menjadi 11px alih-alih 8px yang dimaksudkan (berbasis 16px). Itu deviasi 37%—cukup untuk merusak ritme visual dan memicu tiket bug berlabel “CTA tidak sejajar di iPad”.
Hal yang tidak diberitahukan orang tentang pewarisan em
Kebanyakan tutorial mengatakan “em mewarisi dari ukuran font induk”. Nuansanya: jika Anda mengatur font-size: 1.2em pada div, dan div itu berisi section tanpa ukuran font, properti berbasis em pada section (seperti margin) masih merujuk pada ukuran font terkomputasi div, bukan akar. Tetapi jika Anda mengatur margin: 1em pada div, em itu merujuk pada ukuran font div sendiri, yang mungkin juga berasal dari em. Referensi rekursif inilah tempat bug bersembunyi.
Untuk berapa px 1 em dalam rantai bersarang itu? Itu bisa 19.2px, 22px, atau apa pun. Satu-satunya jawaban aman adalah: periksa gaya terkomputasi di DevTools. Itulah mengapa saya lebih suka rem untuk spasi global dan em hanya untuk hubungan tipografis lokal (seperti judul dan subjudulnya).
Default browser: mengapa 16px adalah konvensi, bukan konstanta
Setiap browser utama (Chrome, Firefox, Safari, Edge) mengirimkan default ukuran font 16px untuk elemen html, tetapi ini dapat dikonfigurasi oleh pengguna. Di Firefox, pengguna dapat mengatur ukuran font minimum; di Chrome, mereka dapat menyesuaikan melalui pengaturan. Modul Nilai dan Unit CSS W3C mendefinisikan nilai awal font-size sebagai medium, yang biasanya 16px tetapi tidak dijamin. Saya telah melihat kios perusahaan di mana basis dipaksa ke 24px untuk keterbacaan.
Itu berarti konversi px-ke-rem apa pun yang mengasumsikan 16px hanya valid jika Anda mereset akar ke 16px secara eksplisit atau menerima default browser. Jika Anda menulis html { font-size: 100% }, Anda mengatakan “gunakan preferensi pengguna,” yang bisa 20px. Maka 24px dalam rem tetap 1.5rem, tetapi 1.5rem menghitung menjadi 30px, bukan 24px. Kehalusan ini menjawab pertanyaan “Berapa 24 px dalam rem?” dengan peringatan: itu 1.5rem apa pun, tetapi pixel yang dirender bergantung pada akar.
Lembar contekan praktis untuk nilai pixel umum (dengan asumsi akar 16px)
Di bawah ini adalah tabel referensi cepat yang saya sematkan di dokumen sistem desain kami. Ini mengasumsikan akar default 16px dan induk 16px untuk kesetaraan em. Gunakan untuk konversi cepat, tetapi ingat em bergeser jika induk berubah.
| Nilai pixel | rem (akar 16px) | em (induk 16px) | Penggunaan umum |
|---|---|---|---|
| 8px | 0.5rem | 0.5em | spasi rapat, batas |
| 12px | 0.75rem | 0.75em | keterangan, teks meta |
| 14px | 0.875rem | 0.875em | body sekunder |
| 16px | 1rem | 1em | teks body dasar |
| 20px | 1.25rem | 1.25em | subjudul |
| 24px | 1.5rem | 1.5em | judul bagian (menjawab “24px dalam rem”) |
| 32px | 2rem | 2em | judul tingkat h2 |
| 48px | 3rem | 3em | teks hero |
| 64px | 4rem | 4em | judul tampilan |
Jika akar Anda diatur ke 10px (trik lama: html { font-size: 62.5% }), maka 1rem = 10px dan 24px menjadi 2.4rem. Saya akan membahas mengapa trik itu sekarang sudah ketinggalan zaman di bagian responsif. Perhatikan juga bahwa persentase memetakan berbeda: 100% = 1em jika font-size diwariskan, tetapi persentase pada lebar tidak terkait.
Contoh kerja: mengonversi px ke em dalam sistem kartu bersarang
Mari kita kaitkan pertanyaan bagaimana cara mengonversi px ke em dalam kode. Misalkan spesifikasi desain mengatakan: padding kartu 32px, ukuran font judul 24px, ukuran font subjudul 16px, padding tombol 12px. Akar 16px. Ukuran font kartu tidak diatur, jadi 1rem (16px).
Konversi dengan rem: padding kartu 2rem, judul 1.5rem, subjudul 1rem, padding tombol 0.75rem. Semua stabil di seluruh aplikasi.
Sekarang anggap kartu menggunakan font-size: 0.875rem (14px) untuk varian ringkas. Jika Anda keras kepala menggunakan em untuk padding tombol karena “em fleksibel”, Anda harus membagi 12px dengan ukuran font induk (14px) → 0.857em, bukan 0.75em. Lewatkan itu dan tombol terlihat sempit. Saya belajar ini ketika klien mengeluh CTA kartu ringkas “melenceng” 2px; itu persis kesalahan penyebut ini, ditemukan hanya setelah diff visual di CI.
Aksesibilitas dan zoom: mengapa rem membantu pengguna dan memenuhi standar
Argumen terkuat untuk rem adalah kontrol pengguna. Ketika pengguna dengan gangguan penglihatan mengatur ukuran font default browser mereka menjadi 20px (atau menggunakan zoom halaman), tata letak berbasis rem akan menyesuaikan secara proporsional, sementara teks dengan px tetap kecil. Menurut Modul Nilai dan Unit CSS W3C, unit panjang relatif dirancang untuk beradaptasi dengan preferensi pengguna, yang sejalan dengan kriteria keberhasilan WCAG 2.1 1.4.4 (mengubah ukuran teks).
Dalam audit tahun 2022 terhadap portal layanan kesehatan, kami menemukan bahwa beralih dari px ke rem untuk semua ukuran font dan jarak utama mengurangi laporan kerusakan tata letak sekitar 40% di antara pengguna yang memperbesar hingga 150%. Hal yang sering terlewat: em juga bisa diskalakan, tetapi jika Anda menggunakan em untuk lebar kontainer berdasarkan induk yang tidak diskalakan, Anda akan mendapatkan proporsi yang tidak cocok. Rem menyediakan satu sumber kebenaran.
Namun, saya tidak akan berpura-pura bahwa rem adalah solusi ajaib. Nilai piksel masih memiliki tempat untuk border (1px), bayangan, dan terkadang titik henti media query (meskipun breakpoint rem semakin populer). Trade-off-nya adalah prediktabilitas vs adaptabilitas. Dari tinjauan saya terhadap kode sumber Bootstrap 5, Tailwind CSS, dan Material UI, ketiganya menggunakan rem sebagai default untuk jarak dan skala font sambil menyisakan px untuk border tipis.
Penskalaan responsif dengan mengubah ukuran font root
Salah satu teknik yang mengubah alur kerja saya adalah memanipulasi ukuran font root dengan media query atau fungsi fluida, lalu membiarkan rem menangani sisanya. Alih-alih menulis puluhan media query untuk setiap komponen, Anda menskalakan root dan melihat semuanya menyesuaikan.
Strategi penskalaan font dasar saya menggunakan clamp()
Sekarang saya menggunakan rumus root fluida: html { font-size: clamp(16px, 1vw + 14px, 20px); }. Ini menjaga teks dasar antara 16px dan 20px tergantung pada lebar viewport. Akibatnya, judul 1.5rem (24px pada basis 16px) menjadi 30px di layar besar tanpa kode tambahan. Itu adalah skala tipografi responsif dengan satu baris.
Sebelumnya, “trik 62,5%” (mengatur root menjadi 10px) populer karena membuat perhitungan mental menjadi mudah: 24px = 2.4rem. Tetapi itu merusak zoom pengguna di beberapa versi IE lama dan memaksa Anda untuk menimpa root demi aksesibilitas. Pendekatan clamp menghormati default pengguna sambil memberikan kontrol kepada desainer. Saya telah menerapkan ini di tiga proyek Vue dan React sejak 2023 tanpa bug regresi dalam tes Storybook.
Jika Anda perlu mendukung browser lama tanpa clamp, gunakan media query bertahap: @media (min-width: 1200px) { html { font-size: 18px; } }. Kuncinya adalah: tentukan strategi root Anda sebelum mengonversi px ke rem, karena penyebut konversi berubah secara global.
Aturan keputusan: kapan menggunakan px, em, atau rem di proyek nyata
Setelah bertahun-tahun mencoba, saya menggunakan matriks keputusan sederhana. Ini adalah kerangka kerja yang saya harap pesaing terbitkan alih-alih hanya kalkulator.
- Gunakan px untuk: border 1px, box-shadow, offset posisi absolut yang tidak boleh diskalakan, dan saat menyelaraskan ke kisi piksel kaku dalam pembuatan prototipe.
- Gunakan rem untuk: ukuran font, margin/padding untuk kontainer tata letak, lebar media query, dan jarak apa pun yang harus menghormati preferensi font pengguna. Ini adalah default Anda untuk hampir semua hal.
- Gunakan em untuk: proporsi internal komponen di mana Anda secara sengaja ingin penskalaan relatif terhadap ukuran font lokal—misalnya, padding tombol di dalam judul, atau ukuran karet dropdown relatif terhadap labelnya. Hindari em untuk tata letak luar.
Tanyakan pada diri sendiri: “Jika pengguna menaikkan font browser mereka menjadi 20px, haruskah nilai ini tumbuh?” Jika ya, gunakan rem. Jika “haruskah tumbuh hanya ketika komponen induknya tumbuh?” maka gunakan em. Jika “tidak pernah,” gunakan px.
Aturan praktis: rem untuk ritme global, em untuk harmoni lokal, px untuk detail yang tidak berubah.
Kesalahan umum dan cara men-debug-nya
Bahkan dengan rumus yang tepat, hal-hal bisa salah. Berikut adalah kasus tepi yang saya temui di produksi:
- Perkalian em yang tidak terduga: Sebuah
lidenganfont-size: 0.9emdi dalamulyang sudah 0.9em akan menjadi 0.81em. Gunakan rem untuk item daftar kecuali Anda menginginkan penyusutan itu. - Ukuran font root ditimpa oleh framework: Bootstrap 4 mengatur
html { font-size: 16px }tetapi beberapa reset mengatur 100%. Jika Anda menggunakan konverter yang mengasumsikan 16px dan framework menggunakan 100% (yang merupakan 16px tetapi dapat dimodifikasi pengguna), itu tidak masalah—sampai pengguna mengubah default browser. Uji dengan default 20px di Firefox. - Line-height dalam em:
line-height: 1.5empada elemen dengan font-size 20px menghasilkan line-height 30px, tetapi jika diwariskan, itu tetap pada ukuran font elemen itu sendiri, bukan induknya. Gunakan line-height tanpa unit (1.5) untuk menghindari jebakan ini. - Mengonversi px ke em tanpa mengetahui induk: Jika Anda bertanya “bagaimana mengonversi px ke em” untuk nilai di dalam kartu dengan font-size 14px, 24px = 1.714em, bukan 1.5em. Selalu periksa induk yang dihitung.
Bug paling licik yang saya temui adalah variabel CSS --space: 1em yang didefinisikan pada :root. Karena :root adalah elemen html, em itu sebenarnya sama dengan rem (karena induk root adalah 16px awal). Tetapi di dalam komponen yang mendefinisikan ulang --space: 1em secara lokal, itu berubah. Variabel tidak menangkap sifat “relatif terhadap tempat digunakan” secara otomatis—mereka disubstitusi sebagai token. Itu adalah jebakan halus yang layak didokumentasikan dalam panduan gaya Anda.
Menggunakan Sass dan PostCSS untuk mengotomatiskan konversi dengan aman
Jika Anda bekerja dengan Sass, fungsi @function rem($px, $base: 16) { @return math.div($px, $base) * 1rem; } mengodekan asumsi tersebut. Tetapi meng-hardcode 16 mengabaikan penimpaan pengguna. Saya lebih suka meneruskan $base dari variabel global yang cocok dengan root. Plugin PostCSS seperti postcss-pxtorem dapat mengonversi pada waktu build, tetapi mereka mengonversi semua px ke rem secara membabi buta, yang dapat merusak border 1px jika tidak dikonfigurasi dengan minPixelValue. Dalam satu proyek, kami mengirimkan border buram karena plugin mengonversi 1px menjadi 0.0625rem dan browser membulatkan dengan buruk di retina. Selalu kecualikan nilai 1px dan 0.
Untuk konversi em, saya tidak mengotomatiskan; saya memverifikasi konteks induk secara manual karena alat build tidak dapat mengetahui nesting DOM saat runtime. Keterbatasan jujur ini adalah alasan mengapa kalkulator saja tidak cukup.
Pengujian dan otomatisasi: menangkap kesalahan unit sebelum deploy
Dalam pipeline CI untuk sistem desain, saya menambahkan aturan Stylelint scale-unlimited/declaration-strict-value untuk melarang px untuk ukuran font kecuali 0 dan 1px. Ini memaksa setiap kontributor untuk secara sadar memilih rem atau em. Selama enam bulan, tiket bug tata letak turun secara signifikan. Trade-off-nya: onboarding memakan waktu lebih lama karena junior harus belajar konversi. Tetapi kemenangan jangka panjangnya jelas.
Saya juga menulis tes snapshot Jest yang merender komponen pada ukuran font root 20px dan menegaskan tidak ada kotak pembatas yang tumpang tindih. Tes itu menangkap bug penggabungan em di komponen breadcrumb yang tidak akan pernah terungkap oleh konverter px.
Menyatukan semuanya: alur kerja konversi langkah demi langkah
Berikut adalah proses pasti yang saya ikuti saat menerima spesifikasi piksel dari desainer:
- Konfirmasi strategi ukuran font akar (default 16px, atau formula clamp). Dokumentasikan di README.
- Untuk setiap nilai piksel, tentukan unit menggunakan matriks keputusan di atas.
- Jika rem: bagi dengan akar (misalnya, 24px → 1.5rem). Jika em: bagi dengan ukuran font induk yang diketahui (misalnya, induk 14px → 24px = 1.714em).
- Gunakan Konverter Piksel ke EM/REM kami untuk memverifikasi matematika dua arah, tetapi sesuaikan penyebut em secara manual per komponen.
- Buka devtools browser, emulasikan zoom 150% atau atur akar ke 20px, dan periksa komponen bersarang untuk penyimpangan em yang terkompon.
- Tambahkan komentar di CSS yang mencatat asumsi dasar untuk pemelihara di masa depan.
Alur kerja ini telah menyelamatkan saya dari setidaknya belasan regresi tata letak di tema React dan WordPress produksi. Butuh 5 menit ekstra per stylesheet tetapi menghilangkan berjam-jam QA.
Pertimbangan lanjutan: em untuk pustaka komponen fluid
Jika Anda membangun pustaka komponen yang dapat digunakan ulang (seperti paket npm), em bisa sangat kuat. Misalkan Anda mengirim komponen .badge di mana padding adalah 0.4em dan ukuran font diatur oleh konsumen. Badge akan menyesuaikan dengan sempurna dengan ukuran font apa pun yang diterapkan aplikasi host. Itu tidak mungkin dengan rem (yang akan mengabaikan konteks konsumen) atau px (yang akan kaku). Saya menggunakan ini di plugin Tailwind di mana pengguna mengatur font dasar pada pembungkus, dan semua badge anak menyesuaikan.
Namun, trade-offnya adalah bahwa jarak internal komponen Anda bisa meledak jika konsumen secara tidak sengaja mengatur ukuran font ke 40px. Berikan pengaman: atur ukuran font maksimum atau gunakan rem untuk penahan luar. Matriks keputusan tetap berlaku, hanya di batas pustaka.
Catatan akhir tentang penguasaan piksel ke em rem
Menguasai cara mengonversi piksel ke em rem bukan tentang menghafal pembagi; ini tentang memahami kaskade. Default 16px adalah konvensi, bukan hukum. Setelah Anda menginternalisasi bahwa 1em adalah pertanyaan (“seberapa besar induk saya?”) dan 1rem adalah pernyataan (“saya percaya pada akar”), CSS Anda menjadi dapat diprediksi dan dapat diakses.
Baik Anda memperbaiki situs warisan atau membangun sistem desain baru, mulailah dengan akar, pilih unit berdasarkan niat, dan verifikasi dengan zoom nyata. Itulah jalur praktisi melampaui kalkulator.