Convertisseur d'unités CSS, gratuit
Convertissez entre px, rem, em, vw, vh, pt, cm, mm, in et % avec un contexte configurable.
Réglages de contexte
Convertir
Résultats
Référence des unités CSS
Unités absolues
- px · pixels (1/96 de pouce)
- pt · points (1/72 de pouce)
- cm · centimètres
- mm · millimètres
- in · pouces
Unités relatives
- rem · relatif à la taille de police racine
- em · relatif à la taille de police parente
- vw · 1 % de la largeur de la fenêtre
- vh · 1 % de la hauteur de la fenêtre
- vmin · 1 % de la plus petite dimension de fenêtre
- vmax · 1 % de la plus grande dimension de fenêtre
- % · pourcentage de l'élément parent
Quand utiliser rem ou em ?
Utilisez rem pour un dimensionnement cohérent (marges, padding, tailles de police) · il fait toujours référence à la racine. Utilisez em quand vous voulez un dimensionnement relatif au parent, comme des composants imbriqués qui s'adaptent à leur contexte.
Pourquoi px n'est-il pas toujours égal à un pixel physique ?
Le px CSS est un « pixel de référence » défini comme 1/96 de pouce à distance de bras. Sur les écrans haute densité (HiDPI), un px CSS peut correspondre à 2 ou 3 pixels physiques.
Le pixel de référence CSS, la clé de voûte de toute unité absolue
Les unités absolues de CSS (in, cm, mm, Q, pt, pc, px) sont ancrées au pixel de référence CSS. Le module W3C CSS Values and Units Level 3 le définit comme « l'angle visuel d'un pixel sur un appareil dont la densité de pixels est de 96 dpi et à une distance d'une longueur de bras du lecteur ». Pour une longueur de bras d'environ 28 pouces, cet angle visuel est d'à peu près 0,0213°, soit environ 0,26 mm de largeur d'écran physique à une distance de visionnage typique, et la spécification illustre que le même angle visuel correspond à environ 1,3 mm à 12 pieds, ce qui explique pourquoi les pixels de projecteur et de téléviseur peuvent être physiquement plus grands tout en comptant chacun pour un seul pixel CSS.
Pour les écrans, la spécification définit en CSS 1in = 96 px plutôt que de dériver des pouces réels de l'écran. Cela signifie que les conversions du tableau ci-dessus sont exactes et ne dépendent pas du DPI de l'affichage : 12 pt valent toujours 16 px, 1 pc vaut toujours 16 px, 1 mm vaut toujours environ 3,78 px. Sur un affichage à haute densité (Retina, 4K), le système d'exploitation fait correspondre chaque pixel CSS aux pixels physiques qui approchent le mieux l'angle visuel, typiquement 2 pixels physiques par pixel CSS sur un MacBook Retina, 3 sur un iPhone Pro, 1,5 sur un bureau Windows à une mise à l'échelle de 150 %. Une bordure 1px nette sur un écran Retina occupe 2 pixels physiques.
Les unités relatives à la police
Celles-ci se résolvent par rapport à la typographie plutôt qu'à des pouces physiques. Elles constituent le socle des mises en page accessibles et adaptables.
L'em est la pierre angulaire, avec une profondeur historique surprenante : il précède CSS d'environ 500 ans. Dans l'impression au plomb mobile (post-Gutenberg, vers 1450), le « cadratin » (em quad) était un bloc de métal carré dont la largeur égalait la hauteur du corps de la fonte, approchant historiquement la largeur du M majuscule. CSS emprunte l'abstraction : 1em égale la taille de police calculée de l'élément courant. Le piège célèbre est que les déclarations font-size: 1.2em imbriquées se multiplient ; un enfant en 1.2em à l'intérieur d'un parent en 1.2em s'affiche à 1,44× la taille du grand-parent.
Le rem (« root em ») a été ajouté dans CSS3 pour résoudre exactement ce problème de cumul. 1rem égale la taille de police de l'élément racine <html>, non affectée par l'imbrication des parents. Les navigateurs fixent la racine par défaut à 16 px à moins que l'utilisateur ne la remplace, de sorte que 1rem = 16px dans les conditions par défaut. Le rem est apparu dans Safari 4.1 et Firefox 3.6 en 2010, IE9 en mars 2011 ; IE8 ne l'a jamais pris en charge, ce qui a imposé des solutions de repli en px jusque vers 2014.
Les unités relatives à la police plus récentes (CSS Values 4) incluent ch (la largeur du caractère « 0 » dans la police courante, utile pour les largeurs maximales de longueur de ligne comme max-width: 60ch ou 66ch, qui se situent dans la plage de lecture typographiquement idéale de 45 à 75 caractères), ex (la hauteur d'x de la police), cap (la hauteur de capitale), ic (la chasse de l'idéogramme CJC 水), et lh / rlh (la hauteur de ligne calculée de l'élément / de la racine, utile pour le rythme vertical).
Les unités en pourcentage de la fenêtre d'affichage (et le problème de la barre d'adresse mobile)
Les quatre classiques, vw, vh, vmin, vmax : représentent 1 % de la largeur de la fenêtre, 1 % de la hauteur de la fenêtre, 1 % de la plus petite des deux, et 1 % de la plus grande. À 1920 × 1080 : 1vw = 19.2px, 1vh = 10.8px.
100vh a longtemps été une plaie sur mobile parce qu'iOS Safari et Chrome Mobile affichent tous deux une barre d'URL qui se rétracte au défilement. Les navigateurs devaient choisir : faire que 100vh égale la fenêtre courte (barre d'URL visible, le contenu est rogné après défilement) ou la haute (barre d'URL masquée, grand espace vide au premier rendu). iOS Safari a choisi le comportement haut, laissant les développeurs déboguer « pourquoi ma section héroïque est-elle plus haute que l'écran ? » pendant des années.
L'effort Interop 2022 (Apple, Google, Igalia, Microsoft, Mozilla et d'autres) a ajouté de nouvelles variantes de fenêtre en mars 2022 pour résoudre ce problème :
- Petite fenêtre (
svw/svh/svmin/svmax), suppose que l'interface du navigateur est entièrement déployée ; la plus petite fenêtre possible. Stable au premier rendu. - Grande fenêtre (
lvw/lvh/ etc.), suppose que l'interface du navigateur est entièrement rétractée ; la plus grande fenêtre possible. - Fenêtre dynamique (
dvw/dvh/ etc.), se met à jour en direct à mesure que l'interface se réduit et s'agrandit. Le meilleur ajustement, mais peut provoquer des redessins pendant le défilement.
Recette pratique : min-height: 100svh sur une section héroïque pour qu'elle ne soit pas rognée sur iOS, ou height: 100dvh sur une fenêtre modale en plein écran. Safari a livré la prise en charge en premier (15.4, mars 2022) ; Firefox 101 (mai 2022) ; Chrome et Edge 108 (décembre 2022). La prise en charge mondiale est désormais très répandue.
Les unités de requête de conteneur
Une famille plus récente, cqw, cqh, cqi, cqb, cqmin, cqmax : permet à un élément de se dimensionner en fonction de son conteneur plutôt que de la fenêtre. Essentielle pour la conception pilotée par composants, où le même composant peut apparaître à 300 px de large dans une barre latérale et à 900 px de large dans une colonne principale. L'unité s'évalue par rapport au conteneur ancêtre le plus proche dont container-type est défini ; si aucun conteneur éligible n'existe, la spécification se replie sur l'unité de petite fenêtre sur cet axe. Les requêtes de conteneur (et leurs unités) sont apparues dans Chromium 105 en 2022, Safari 16 en septembre 2022 et Firefox 110 en février 2023, devenant nouvellement disponibles dans Baseline en 2023.
Les pourcentages, et pourquoi ce n'est pas vraiment une longueur
Les pourcentages ne sont pas une unité de longueur en soi ; ce sont un type de valeur distinct qui se résout selon le contexte :
- Sur
width/height: pourcentage de la taille en ligne / en bloc du parent. - Sur
font-size: pourcentage de la taille de police calculée du parent. - Sur
line-height: pourcentage de la taille de police propre de l'élément. - Sur
marginetpadding, sur les quatre côtés : pourcentage de la taille en ligne du parent (c'est-à-dire la largeur). C'est la source de la fameuse surprise « une marge verticale en % égale l'horizontale ». - Sur
transform: translate(): pourcentage des dimensions propres de l'élément.
En raison de cette résolution contextuelle, % ne peut pas simplement être converti en px sans connaître la dimension du parent ; le convertisseur ci-dessus la demande explicitement.
Conseils pratiques : quand utiliser quoi
- Utilisez rem pour
font-size. Il respecte le réglage de police par défaut du navigateur de l'utilisateur, un vrai gain d'accessibilité, car les utilisateurs malvoyants peuvent mettre à l'échelle globalement plutôt que site par site. - Utilisez em pour les proportions internes aux composants : tailles d'icônes qui doivent s'accorder au texte d'un bouton, marge intérieure d'un bouton qui s'adapte au texte.
- Évitez px sur
font-size. Le zoom du navigateur aide, mais seulement site par site ; le rem respecte aussi le remplacement de la taille de police par défaut de l'utilisateur. - px convient pour les bordures, les éléments décoratifs nets et les ombres, là où l'épaisseur physique compte plus que la mise à l'échelle.
- % pour les mises en page fluides où les enfants doivent remplir leur parent.
- vw / vh pour les sections héroïques, les arrière-plans pleine page et les fenêtres modales : mais optez pour
svhoudvhplutôt quevhsur tout ce qui touche le bas des écrans mobiles. - vmin pour les éléments à aspect carré (avatars, écrans de démarrage) afin qu'ils tiennent dans les deux axes.
- ch pour les largeurs maximales de longueur de ligne dans la prose :
max-width: 60chou66chse situe dans la plage de lecture idéale.
La typographie fluide avec clamp()
clamp(MIN, PREFERRED, MAX) renvoie la valeur préférée, bornée par le plancher et le plafond. Le schéma classique de type fluide combine un plancher et un plafond en rem avec un terme central de mise à l'échelle piloté par vw :
h1 { font-size: clamp(1.8rem, 1.2rem + 2.5vw, 3rem); }
Le terme central s'adapte linéairement à la fenêtre, tandis que le plancher et le plafond fondés sur le rem empêchent les tailles extrêmes et préservent la mise à l'échelle de la police de l'utilisateur. clamp() est devenu largement disponible (Baseline) en juillet 2020 (Chrome 79, Firefox 75, Safari 13.1). Des outils comme Utopia (utopia.fyi) et fluid-type-scale.com prennent des largeurs de fenêtre min / max, des tailles de police min / max et un ratio d'échelle modulaire (1,2, 1,25, 1,333, 1,5, nombre d'or) et produisent des déclarations prêtes à coller.
L'accessibilité : WCAG SC 1.4.4 Redimensionnement du texte
La norme exige que le texte puisse être agrandi à 200 % de sa taille d'origine sans perte de contenu ni de fonctionnalité. Elle n'impose pas d'unité précise, mais les techniques suffisantes listées incluent « utiliser des mesures qui sont relatives à d'autres mesures du contenu » ; les unités relatives (em, rem, %) facilitent la conformité ; les mises en page uniquement en pixels peuvent réussir via le zoom du navigateur, mais sont plus fragiles. Le test mental : cela devrait-il s'adapter lorsque l'utilisateur agrandit la taille de texte par défaut ? Si oui, utilisez rem. Les bordures, la marge intérieure décorative et la décoration pure peuvent rester en px.
Plus de questions
Pourquoi 1in n'est-il pas vraiment un pouce sur mon écran ?
Parce que la spécification CSS ancre les unités absolues à une référence d'angle visuel plutôt qu'à des pouces physiques. Un 1in CSS est défini comme exactement 96 pixels CSS, que le navigateur fait correspondre aux pixels physiques qui approchent le mieux la référence à une distance de visionnage typique. Sur la plupart des moniteurs, cela finit proche d'un pouce réel, mais sur un téléviseur regardé depuis l'autre bout de la pièce, ce sera physiquement plus grand, et sur un ordinateur portable à haute densité posé sur vos genoux, ce pourrait être légèrement plus petit. Pour une mesure physique réelle, utilisez une règle contre l'écran.
Quelle est l'« astuce des 62,5 % » que les gens mentionnent parfois ?
Un schéma très répandu : html { font-size: 62.5%; }. Comme 62,5 % × 16 = 10, cela fait que 1rem = 10px : pratique pour le calcul mental (1.6rem = 16px, 2.4rem = 24px). C'est débattu ; les opposants soutiennent qu'il remplace la taille de police par défaut préférée de l'utilisateur et qu'il est légèrement hostile à l'utilisateur pour l'accessibilité. De nombreuses équipes modernes choisissent un ratio en préservant explicitement le remplacement par l'utilisateur (par exemple, en définissant la taille de police du body en rem pour que la cascade respecte le défaut de l'utilisateur).
Quand devrais-je utiliser vw plutôt que cqw ?
Utilisez vw quand la taille doit suivre la fenêtre (texte héroïque pleine page, fenêtres modales en plein écran). Utilisez cqw quand la taille doit suivre le conteneur du composant : par exemple, un titre de carte plus grand quand la carte est dans la colonne principale et plus petit quand elle est dans une barre latérale, quelle que soit la taille de la fenêtre. Les unités de requête de conteneur sont apparues en 2022-2023 et sont la bonne réponse presque chaque fois que vous auriez sinon recours à une échelle de police pilotée par media query sur un seul composant.
Quelle est la différence entre dpi et dppx dans les requêtes @media ?
Les deux expriment la résolution. dppx signifie « points par pixel CSS », 1dppx = 96dpi, puisque CSS définit 96 px par pouce. @media (min-resolution: 2dppx) cible les affichages de classe Retina où chaque pixel CSS est rendu avec au moins 2 pixels physiques. Utiliser dppx est généralement préférable, car cela évite la confusion entre dpi et pouce CSS.
Quelque chose est-il envoyé à un serveur ?
Non. Les conversions sont de simples calculs JavaScript exécutés localement dans votre navigateur. Rien de vos saisies n'est envoyé où que ce soit ; la page fonctionne hors ligne une fois chargée.