Konverter PX ke REM

Konversi px ke rem dan Sebaliknya, Secara Instan

Konverter px ke rem ini menjaga px, rem, em, dan pt tetap sinkron terhadap root font size apa pun yang Anda pilih. Ubah kolom mana pun dan sisanya diperbarui secara langsung, sehingga berpindah dari mockup desain berbasis piksel ke unit rem CSS yang bisa diskalakan — atau kembali dari rem ke px — tidak memerlukan hitungan mental. Ini konverter unit CSS yang cepat dan gratis, berjalan sepenuhnya di browser Anda tanpa ada yang diunggah.

Tabel referensi di bawah konverter mendaftar semua nilai px umum yang Anda perlukan sehari-hari — salin hasil mana pun dengan satu klik. Ubah root font size dan seluruh tabel menghitung ulang seketika, memudahkan Anda berpindah antara proyek 16px dan proyek 10px (trik 62,5%).

Rumus px ke rem Dijelaskan

Konversinya sederhana: rem = px ÷ root font size. Browser secara default memakai root 16px, sehingga 16px = 1rem, 24px = 1,5rem, dan 40px = 2,5rem. Untuk membaliknya: px = rem × root, sehingga 0,875rem × 16 = 14px. Karena konverternya dua arah, Anda tidak pernah harus mengingat arah mana yang sedang Anda kerjakan — cukup ketik ke kolom yang Anda tahu dan yang lainnya diperbarui.

Trik 62,5% menyederhanakan ini: atur html { font-size: 62.5%; } untuk membuat root menjadi 10px, lalu nilai rem memetakan dengan bersih ke kelipatan 10. 1,6rem = 16px, 2,4rem = 24px, 3,2rem = 32px. Beralih ke preset 10px di sini untuk melihat pemetaan bersih ini di semua nilai umum.

px, rem, dan em — Apa Bedanya?

px adalah unit absolut: 16px selalu 16px. rem relatif terhadap ukuran font elemen root (html), memberikan satu jangkar konsisten untuk seluruh halaman. em relatif terhadap ukuran font induknya sendiri, sehingga menumpuk saat Anda menyarangkan elemen — sebuah paragraf di dalam section pada 1,2em di dalam article pada 1,2em menghasilkan 1,2 × 1,2 = 1,44em, sementara 1,44rem akan tetap flat 1,44× root terlepas dari kedalaman nesting.

Alat ini juga menampilkan pt (1px = 0,75pt) untuk nilai bergaya cetak. Pada root 16px tanpa nesting, 16px, 1rem, dan 1em semuanya setara — perbedaannya baru terlihat setelah ukuran font induk berubah atau pengguna menyesuaikan ukuran teks default browser mereka.

Mengapa Memakai rem untuk Ukuran Font — Aksesibilitas Itu Penting

Mengatur ukuran teks dalam rem alih-alih px adalah peningkatan aksesibilitas yang berarti. Saat pengunjung menaikkan ukuran teks default browser mereka (kebutuhan umum bagi pengguna dengan gangguan penglihatan atau yang membaca di layar high-DPI), setiap ukuran font dan nilai spacing berbasis rem ikut membesar secara proporsional. Nilai px tetap tidak berubah dan bisa menghasilkan layout dengan teks yang menjadi terlalu kecil relatif terhadap kontainernya.

WCAG 2.1 Guideline 1.4.4 mengharuskan teks bisa diperbesar hingga 200% tanpa kehilangan konten atau fungsi. Membangun dengan unit rem secara default membuat pedoman ini jauh lebih mudah dipenuhi — seluruh skala tipografi Anda dan sebagian besar spacing Anda bergeser saat root berubah, menjaga proporsi tetap utuh. Inilah mengapa alat seperti Tailwind CSS secara default memakai unit rem di seluruh sistemnya.

Nilai px ke rem yang Umum — Referensi Cepat

Pada root standar 16px: 8px = 0,5rem, 10px = 0,625rem, 12px = 0,75rem, 13px = 0,8125rem, 14px = 0,875rem, 16px = 1rem, 18px = 1,125rem, 20px = 1,25rem, 24px = 1,5rem, 28px = 1,75rem, 32px = 2rem, 36px = 2,25rem, 40px = 2,5rem, 48px = 3rem, 64px = 4rem.

Inilah nilai-nilai yang paling sering Anda ketik dalam sebuah codebase CSS. Tabel referensi di alat ini mendaftar semuanya dan membiarkan Anda menyalin nilai mana pun dengan satu klik — lebih cepat daripada menghitung manual setiap kali dan lebih kecil kemungkinan salahnya daripada menghafal tabel. Simpan sebagai bookmark kalkulator rem ini dan buka kapan pun Anda perlu menerjemahkan spesifikasi desain dalam piksel ke CSS dalam unit rem.

Privat, Instan, dan Gratis — Tanpa Perlu Daftar

Tidak ada yang perlu diinstal dan tidak perlu daftar. Setiap konversi — px ke rem, rem ke px, px ke em, em ke px — terjadi secara lokal di browser Anda dengan JavaScript. Nilai yang Anda masukkan tidak pernah meninggalkan perangkat Anda dan tidak pernah dikirim ke server mana pun. Berbeda dari beberapa konverter online yang mengharuskan membuat akun atau menonton iklan sebelum mengakses hasil, semuanya di sini tersedia langsung dan tanpa batasan.

Alat ini berfungsi offline setelah dimuat, tanpa batas penggunaan, dan berfungsi di perangkat apa pun — desktop, tablet, iPhone, atau Android. Simpan sebagai bookmark konverter px ke rem ini sebagai alat CSS harian dan bebaskan diri Anda dari hitungan mental setiap kali menerjemahkan spesifikasi desain Figma ke CSS yang bisa diskalakan.

Lanskap Lengkap Unit CSS

CSS menawarkan dua kategori unit panjang: unit absolut dan unit relatif. Set absolut meliputi px, pt (points, 1pt = 1,333px), pc (picas, 1pc = 16px), dan unit fisik cm, mm, dan in. Dari semua ini, hanya px yang praktis dipakai di layar — yang lainnya dirancang untuk cetak dan hanya terpetakan ke dimensi fisik saat perangkat output melaporkan DPI yang akurat, yang tidak dimiliki sebagian besar monitor. Sebuah garis "1cm" pada monitor 96 DPI tidak akan terukur 1 sentimeter jika diukur dengan penggaris.

Set relatif adalah tempat CSS modern hidup. em berskala dengan ukuran font induk langsung elemen tersebut. rem berskala dengan ukuran font elemen root html — satu jangkar global. % relatif terhadap properti setara milik elemen induk. Unit viewport (vh, vw, vmin, vmax) berkaitan dengan dimensi viewport browser. ch sama dengan lebar advance dari glyph "0" pada font saat ini — berguna untuk mengatur sebuah kolom agar tepat selebar N karakter. ex adalah x-height dari font saat ini (kira-kira tinggi huruf kecil "x"), sesekali dipakai untuk ritme vertikal.

Dua tambahan yang lebih baru layak diperhatikan: dvh, svh, dan lvh memecahkan bug "100vh terlalu tinggi" yang terkenal di mobile (dibahas di bawah), dan unit container query cqi dan cqb, diperkenalkan pada 2023, adalah persentase dari ukuran inline atau block container terdekat. cqi dan cqb membuka desain responsif tingkat komponen yang tidak perlu tahu apa pun tentang viewport — sebuah kartu bisa mengubah ukuran berdasarkan kolom tempatnya berada, bukan layar tempatnya ditampilkan.

Mengapa rem Lebih Unggul dari em untuk Ukuran Font

em menumpuk melalui elemen yang bersarang dengan cara yang cepat menjadi sulit dinalar. Jika sebuah Modal mengatur font-size ke 1,25em, dan sebuah Card di dalamnya mengatur font-size ke 1,25em, dan sebuah label di dalam Card itu mengatur font-size ke 1,25em, label tersebut dirender pada 1,25 × 1,25 × 1,25 = 1,953× ukuran dasar — hampir dua kali lipat — tanpa sinyal yang jelas di kode. Tambahkan satu lapisan lagi dan angkanya mencapai 2,44×. Efek penumpukan ini adalah salah satu jebakan tertua di CSS, penyebab tak terhitung sesi debugging "kenapa teks bersarang saya jadi sebesar ini?".

rem menghilangkan penumpukan sepenuhnya karena selalu berjangkar ke elemen root html. Sebuah label yang diatur ke 1,25rem di dalam Card di dalam Modal di dalam Dialog selalu dirender pada tepat 1,25× ukuran font root, terlepas dari berapa banyak leluhurnya yang mengatur font-size sendiri. Prediktabilitas ini adalah alasan mengapa setiap pustaka komponen besar — termasuk Material UI, Chakra, Radix, dan Mantine — secara default memakai rem untuk token tipografi dan spacing.

Konsekuensi praktisnya signifikan bagi design system: saat Anda menyusun komponen, ukuran berbasis rem tetap konsisten sementara ukuran berbasis em mengharuskan penulis melacak secara mental seluruh rantai leluhur untuk tahu berapa ukuran yang akan dirender. Simpan em untuk penskalaan relatif yang disengaja — misalnya, sebuah ikon yang seharusnya berukuran 1,2em agar berskala dengan ukuran font teks sebelahnya — alih-alih sebagai unit font-size umum.

Trik Root Font-Size 62,5% — Populer tapi Kontroversial

Trik 62,5% mengatur html { font-size: 62.5%; }, yang pada default browser 16px menghasilkan 10px. Ini membuat aritmetika rem menjadi sangat sederhana: 1,6rem = 16px, 2,4rem = 24px, 3,2rem = 32px. Setiap nilai rem hanyalah nilai piksel dibagi 10, yang menurut banyak developer lebih mudah dibaca dan ditulis daripada membaginya dengan 16 (yang jarang menghasilkan angka bulat — 14px menjadi 0,875rem yang kurang intuitif).

Masalahnya, ini menimpa preferensi ukuran font browser pengguna. Saat pengguna mengatur default browser mereka ke 20px demi keterbacaan — kebutuhan umum bagi pengguna dengan penglihatan lemah, atau siapa pun yang membaca di layar besar dari jarak jauh — html { font-size: 62.5%; } membuat 62,5% dari 20px = 12,5px menjadi root baru. Setiap nilai rem di situs kini berjangkar ke 12,5px alih-alih 20px yang dimaksudkan pengguna. Ukuran font berbasis rem apa pun kini menjadi lebih kecil dari yang dibutuhkan pengguna, bukan lebih besar. Teknik ini justru menggagalkan seluruh manfaat aksesibilitas dari penggunaan rem sejak awal.

WCAG 2.1 Success Criterion 1.4.4 (Resize Text, Level AA) mengharuskan teks bisa diperbesar hingga 200% tanpa kehilangan konten atau fungsi. Trik 62,5% tidak secara langsung melanggar ini jika Anda hanya memakainya untuk jalan pintas matematika, tetapi ini secara substansial mengikis penghormatan terhadap preferensi ukuran font pengguna yang seharusnya diberikan rem. Pendekatan yang lebih bersih adalah menjaga root pada defaultnya (atau pada persentase seperti 100% yang secara eksplisit mengikuti pengaturan pengguna) dan menerima bahwa 0,875rem hanyalah cara Anda menulis 14px. Konverter di sini bisa membantu Anda membangun intuisi untuk nilai-nilai berbasis 16 sehingga pembagian mental menjadi kebiasaan alami.

Kapan px Menjadi Pilihan yang Tepat

Meski ada alasan kuat untuk rem, beberapa properti CSS sebaiknya tetap dalam px. Lebar border adalah contoh paling jelas: border: 1px solid seharusnya dirender sebagai tepat satu piksel perangkat — garis hairline yang tajam. Jika Anda menulis border: 0.0625rem solid (yang setara 1px pada root 16px), garisnya akan membesar secara proporsional saat pengguna menaikkan root font size mereka, mengubah border dekoratif 1px Anda menjadi garis 1,25px atau 1,5px yang bisa terlihat berat atau buram pada batas subpiksel. Box shadow dan outline memiliki karakteristik serupa — blur radius dan spread-nya sering kali merupakan pilihan estetika yang seharusnya tetap konstan.

Breakpoint media query dalam px adalah pilihan yang disengaja di sebagian besar framework, meski perdebatannya masih hidup. Memakai rem di media query berarti pengguna yang mengatur default browser mereka ke 20px akan menyentuh "breakpoint 768px" Anda pada lebar viewport sebenarnya 768 × (20/16) = 960px — layout sempit mereka terpicu lebih lambat dari yang dimaksudkan. Beberapa tim menganggap ini sebagai fitur (layout merespons lebar konten efektif pengguna), yang lain menganggapnya sebagai jebakan. Tailwind CSS memakai breakpoint px; framework yang menargetkan aksesibilitas maksimal terkadang memakai breakpoint rem. Ketahui perilaku mana yang Anda inginkan sebelum memutuskan.

Gambar dengan dimensi piksel yang diketahui, ikon SVG yang harus presisi piksel, dan elemen yang ukurannya terikat pada aset beresolusi tetap (favicon 32×32 yang tertanam di halaman, sprite sheet) semuanya kandidat yang baik untuk px. Aturan praktisnya: gunakan px saat Anda mendeskripsikan sesuatu yang ada dalam piksel perangkat (border, grafis pixel-art, foto berdimensi diketahui) dan rem saat Anda mendeskripsikan sesuatu yang seharusnya berskala dengan konteks membaca (teks, whitespace, jarak layout).

Pembahasan Mendalam Unit Viewport: vh, vw, dvh, dan Bug Mobile

Unit viewport vh dan vw masing-masing adalah persentase dari tinggi dan lebar viewport browser — 100vh berarti "tinggi penuh jendela browser". Di desktop ini bekerja sesuai harapan, tetapi di browser mobile ini menyebabkan salah satu bug layout paling meluas dalam sejarah CSS: browser mobile menyertakan address bar dan chrome navigasi bawah dalam perhitungan 100vh mereka. Sebuah section hero yang diatur ke 100vh akan meluas hingga di belakang UI browser, terpotong atau menyebabkan offset scroll pada pemuatan pertama. Address bar menyembunyikan diri saat pengguna menggulir, yang kemudian mengubah tinggi yang tersedia di tengah sesi.

Solusi tahun 2022 adalah tiga unit baru: svh (small viewport height — tinggi viewport saat chrome browser sepenuhnya terlihat, ruang terkecil yang tersedia), lvh (large viewport height — tinggi saat chrome sepenuhnya tersembunyi, ruang terbesar yang pernah tersedia), dan dvh (dynamic viewport height — diperbarui secara real time saat chrome muncul atau menghilang). Untuk section setinggi penuh, min-height: 100dvh kini menjadi jawaban modern yang benar. Ketiga unit ini didukung di Chrome 108+, Safari 15.4+, Firefox 101+, dan Edge 108+, sehingga aman dipakai di produksi.

vw punya keanehannya sendiri di Windows: ia menyertakan lebar scrollbar vertikal dalam perhitungannya. Pada halaman dengan scrollbar yang terlihat, width: 100vw akan meluas sedikit melampaui area konten dan menciptakan overflow horizontal. Perbaikannya adalah memakai width: 100% pada elemen block (yang secara alami mengecualikan scrollbar) dan menyimpan vw untuk kasus di mana Anda benar-benar butuh referensi lebar-viewport yang independen dari dokumen — heading tipografi besar yang seharusnya mengikuti lebar layar, misalnya, dengan rumus seperti font-size: clamp(1.5rem, 5vw, 4rem) yang menggabungkan batas bawah/atas rem dengan bagian tengah vw yang fluid.