Convertitore gratuito da PX a REM
Converti pixel in rem e viceversa con una dimensione del carattere di base configurabile.
Tabella di riferimento
| PX | REM |
|---|
Come funziona
REM significa «root em» ed è relativo alla dimensione del carattere dell'elemento radice. Per impostazione predefinita, i browser usano 16 px. La formula è semplice: rem = px ÷ base e px = rem × base. Modifica la dimensione di base sopra se il tuo progetto utilizza una radice diversa.
Domande frequenti
Perché usare rem invece di px?
Le unità REM si adattano all'impostazione della dimensione del carattere del browser dell'utente, migliorando l'accessibilità. Se un utente aumenta la sua dimensione predefinita, i layout basati su rem si adattano automaticamente, mentre i valori in pixel restano fissi.
Qual è la differenza tra em e rem?
EM è relativo alla dimensione del carattere dell'elemento padre e può accumularsi negli elementi annidati. REM è sempre relativo alla dimensione del carattere dell'elemento radice (<html>), il che lo rende più prevedibile.
Quale base devo usare?
La maggior parte dei progetti usa il valore predefinito del browser di 16 px. Alcuni sviluppatori impostano html { font-size: 62.5%; } (10 px) per calcoli più semplici. Usa la dimensione del carattere radice impostata per il tuo progetto.
Cos'è davvero rem
«Rem» sta per root em. La specifica W3C CSS Values Level 3 lo definisce come «uguale al valore calcolato di font-size sull'elemento radice», ovvero sull'elemento <html>. I browser impostano <html> di default a 16px salvo override, quindi su una pagina vanilla 1rem = 16px, 0.5rem = 8px, 1.5rem = 24px, 2rem = 32px.
Se un foglio di stile dichiara html { font-size: 20px }, allora 1rem = 20px per il resto del documento. Se l'utente ha alzato il valore predefinito del browser a 24px (un adattamento comune per ipovedenti), 1rem = 24px anche senza alcun override nel foglio di stile, e questo è l'intero argomento di accessibilità per rem in una frase.
Perché rem è importante: il caso dell'accessibilità
I browser espongono agli utenti due diversi meccanismi di scalatura, che si comportano in modo diverso rispetto alle unità:
- Zoom del browser (Cmd/Ctrl + o pinch), scala uniformemente l'intero viewport. Un elemento da 16px allo zoom del 200% occupa lo stesso spazio sullo schermo di un elemento da 32px al 100%. Sia
pxcheremsi scalano in modo identico con lo zoom, quindi lo zoom da solo non giustifica l'uso di rem. - Preferenza per la dimensione predefinita del carattere del browser: sepolta nelle impostazioni del browser (Firefox
about:preferences, «Personalizza caratteri» di Chrome). Quando l'utente cambia la «Dimensione predefinita del carattere» da 16 a 24 (molto comune per gli ipovedenti), l'elemento<html>inizia a calcolare a 24px. Ogni valoreremsi scala automaticamente di 1,5×; ogni valorepxfisso rimane esattamente lo stesso.
Ecco perché un layout costruito in rem rispetta la preferenza di accessibilità dell'utente e uno costruito in px no. Il Criterio di successo WCAG 2.2 1.4.4 (Ridimensionamento del testo, Livello AA) richiede che il testo possa essere ingrandito ad almeno il 200% senza perdita di contenuto o funzionalità. Lo zoom del browser da solo lo supera tecnicamente, ma i layout basati su rem lo superano in modo più netto perché rispettano il meccanismo più granulare della dimensione predefinita del carattere, che è quello che gli utenti ipovedenti regolano effettivamente ogni giorno.
Il problema del compounding di em che motiva rem
Prima di rem, l'unico modo per ottenere tipografia scalabile in CSS era em, relativo alla dimensione del carattere dell'elemento genitore, non alla radice. Il problema classico: gli elementi annidati con dimensioni del carattere basate su em si moltiplicano.
.list { font-size: 1.2em; }
.list .list { font-size: 1.2em; } /* renders at 1.44× the grandparent */
.list .list .list { font-size: 1.2em; } /* now 1.728× */Tre liste annidate si gonfiano a quasi il doppio della dimensione del corpo, il che non è quasi mai intenzionale. rem risolve questo ancorando alla radice ogni volta; tre elementi annidati a 1.2rem sono tutti a 19,2px indipendentemente dalla profondità di annidamento. Ecco perché la maggior parte dei fogli di stile moderni usa rem per font-size e riserva em alle proporzioni interne ai componenti (dimensioni delle icone che dovrebbero corrispondere al testo del pulsante, padding all'interno di un pulsante che si scala con la sua etichetta).
Il trucco del 62,5%, matematica comoda, accessibilità discutibile
Uno schema reso popolare da Jonathan Snook nel suo articolo del maggio 2011: impostare html { font-size: 62.5% }. Poiché 62,5% × 16 = 10, questo rende 1rem = 10px di default, matematica mentale comoda. 1.6rem = 16px, 2.4rem = 24px, 4.8rem = 48px. Ai designer piaceva perché elimina la scomoda aritmetica del «dividi per 16» da ogni valore.
La critica all'accessibilità (sollevata all'epoca e ribadita in scritti successivi): impostare la dimensione del carattere della radice al 62,5% riduce effettivamente qualsiasi valore che l'utente abbia scelto nelle preferenze del browser. Un utente che ha impostato il valore predefinito a 24px perché è ipovedente vedrebbe il testo del corpo a 15px, vanificando l'intero scopo dell'uso di rem. La risposta moderna è impostare la radice al 62,5% ma dichiarare esplicitamente la dimensione del carattere del corpo a 1.6rem (tornando a 16px) in modo che l'override dell'utente cascadi correttamente. Molti team saltano completamente il trucco e vivono con la matematica leggermente meno elegante.
Quando usare rem, quando usare px, l'inquadratura di Comeau
L'articolo di Josh W. Comeau «px o rem?» (maggio 2022, aggiornato maggio 2025) offre l'euristica a domanda singola più utile per questa decisione. Chiedere: «Questo valore dovrebbe scalare al rialzo quando l'utente aumenta la dimensione predefinita del carattere del browser?» Se sì, usare rem. Se no, usare px.
Con quel test:
- Usare rem per: font-size, margini/padding verticali (legati al ritmo tipografico), larghezze dei pulsanti e altri contenitori a forma di contenuto, max-width della lunghezza delle righe, breakpoint (così il layout si sposta alla giusta dimensione ingrandita per gli utenti ipovedenti).
- Usare px per: i bordi (un filetto da 1px dovrebbe restare un filetto), padding/decorazione orizzontale, raggi delle ombre, dimensioni delle immagini quando l'immagine ha un intento a pixel fisso, dimensioni fini delle icone.
Il test a domanda singola produce risposte coerenti per migliaia di decisioni in una codebase, che è il vero vantaggio: i fogli di stile risultanti si comportano nel modo in cui gli utenti si aspettano sia sotto lo zoom che sotto la personalizzazione della dimensione del carattere.
Tailwind CSS 4 ha adottato rem ovunque
Tailwind CSS v4.0 (gennaio 2025) ha introdotto una scala predefinita completamente basata su rem. Ogni token tipografico (da text-xs 0,75rem a text-9xl 8rem) e ogni token di spaziatura (p-1 0,25rem, p-4 1rem, m-8 2rem) è in rem di default. Tailwind 4 lascia deliberatamente la radice <html> al valore predefinito del browser di 16px (non applica esplicitamente il trucco del 62,5%) in modo che le preferenze di accessibilità dell'utente si propaghino correttamente. Decine di milioni di progetti ora distribuiscono design system basati su rem di default, il che è l'argomento più forte che l'ecosistema sia convergito.
Tabella di conversione con la radice predefinita a 16px
| Pixel | Rem | Uso comune |
|---|---|---|
| 8 px | 0.5 rem | Metà dell'unità base, spaziatura piccola |
| 12 px | 0.75 rem | Didascalia / nota a piè di pagina |
| 14 px | 0.875 rem | Testo secondario |
| 16 px | 1 rem | Testo del corpo predefinito |
| 18 px | 1.125 rem | Corpo leggermente enfatizzato |
| 20 px | 1.25 rem | Paragrafo di apertura |
| 24 px | 1.5 rem | Intestazione H4; testo UI di grandi dimensioni |
| 32 px | 2 rem | Intestazione H3 |
| 48 px | 3 rem | Intestazione H2 / hero |
| 64 px | 4 rem | Intestazione H1 / display |
Il posto di rem nel toolkit moderno
Rem è il valore predefinito corretto per la tipografia e la spaziatura ancorata alla tipografia, ma non è la risposta a ogni problema di layout. Il toolkit moderno include anche:
- clamp() per la tipografia fluida,
font-size: clamp(1rem, 0.8rem + 1vw, 1.5rem)imposta un pavimento e un soffitto in rem con un punto intermedio guidato dal viewport. Convertitore di unità di misura CSS - Unità di viewport (
vw,vh, e le più recentisvh/lvh/dvhper mobile), per le sezioni hero e gli elementi full-bleed che dovrebbero scalare con il viewport piuttosto che con la tipografia. - Unità di container query (
cqw,cqh), per il design component-driven dove lo stesso componente può apparire a larghezze diverse.
Per tutto il resto (testo del corpo, intestazioni, padding, larghezze dei pulsanti, breakpoint) rem è il percorso di minor resistenza e il default più accessibile.
Altre domande
E se il mio progetto usa una dimensione del carattere base non predefinita?
Modificare il campo Base font size in alto al valore a cui si risolve html { font-size: … } del progetto. La matematica di conversione rimane rem = px ÷ base indipendentemente dalla base. Se la codebase usa 18px, 32px diventa 1.78rem; a 10px (il trucco del 62,5%) diventa 3.2rem. Tenere presente che l'override della dimensione del carattere della radice ha implicazioni di accessibilità per gli utenti che personalizzano il valore predefinito del browser; vedere la discussione sul trucco del 62,5% sopra.
Perché 0,625rem non si renderizza esattamente a 10px?
Matematicamente sì, con la radice predefinita a 16px: 0.625 × 16 = 10. Ma i browser renderizzano con precisione al subpixel e possono agganciare i valori finali a pixel interi del dispositivo, quindi un bordo 0.625rem può occasionalmente apparire leggermente diverso da un bordo 10px hardcoded a seconda del DPR del monitor. Per i filetti da 1 pixel perfetti, usare 1px direttamente; per tutto il resto, il valore basato su rem va bene.
Posso mescolare rem e px nello stesso foglio di stile?
Sì, e dovreste farlo. Usare rem per le cose che dovrebbero scalare con la preferenza font-size dell'utente (tipografia, ritmo verticale, breakpoint) e px per le cose che non dovrebbero (bordi, dettagli delle icone, ombre decorative). La domanda di Comeau «questo dovrebbe scalare?» è il filtro pratico; la risposta corrisponde in modo chiaro a un'unità o all'altra quasi sempre.
Gli strumenti di build convertono automaticamente px in rem?
Sì, plugin PostCSS come postcss-pxtorem e postcss-rem-to-responsive-pixel possono riscrivere i valori px nel CSS scritto a mano in rem durante la fase di build, con soglie configurabili (ad es., «convertire qualsiasi cosa ≥ 12px»). Sono utili quando si migra una codebase esistente con molti px. Un converter live come questa pagina è ancora utile per casi isolati, consultazione delle specifiche di design e apprendimento della matematica a mano.
Vengono inviati dati a un server?
No. La conversione è una divisione, pura aritmetica JavaScript che gira localmente nel browser. Nulla del vostro input lascia la pagina; lo strumento funziona offline una volta caricato.