Convertisseur PX en REM & REM en PX
Convertissez instantanément PX en REM et REM en PX avec taille de police racine personnalisée. Générez du CSS clamp() fluide, des classes Tailwind et des tables de conversion.
Convertissez instantanément PX en REM et REM en PX avec taille de police racine personnalisée. Générez du CSS clamp() fluide, des classes Tailwind et des tables de conversion.
Convertissez instantanément PX en REM et REM en PX avec taille de racine personnalisée. Générez du CSS clamp() fluide, des classes Tailwind et des tables de conversion.
Longueur exacte en coordonnées d'écran exprimée en pixels de référence CSS (1px = 1/96e de pouce selon la norme W3C CSS Values). Sert d'ancrage dans les maquettes Figma, Sketch ou Adobe XD avant la conversion relative.
Valeur calculée de la propriété font-size sur l'élément racine <html> du document. Les standards W3C fixent cette valeur par défaut à 16px sur navigateurs desktop et mobiles, établissant 1.000rem = 16px.
Longueur proportionnelle obtenue en divisant les pixels cibles par la base racine (REM = PX Cible / PX Base). S'ajuste dynamiquement au zoom du navigateur et aux réglages d'accessibilité du système d'exploitation.
Intervalle de largeur d'écran (généralement de 375px sur mobile à 1440px sur desktop) sur lequel la typographie s'ajuste proportionnellement avant de se verrouiller aux seuils clamp() minimal et maximal.
Nombre de chiffres après la virgule conservés dans la valeur rem convertie. Une précision de 4 décimales (ex. 0.0625rem pour 1px sur une base de 16px) garantit l'absence d'artefacts d'arrondi sous-pixel sur écrans haute densité (Retina/HiDPI).
Jeton d'espacement ou de taille de police Tailwind CSS v3/v4 correspondant à la valeur rem calculée, indexé sur les incréments standard de 0.25rem (4px) de Tailwind.
Définir font-size en pixels (ex. font-size: 16px) écrase les préférences de taille de police configurées par les utilisateurs malvoyants dans leur navigateur. Les moteurs de rendu ne respectent l'agrandissement utilisateur que si le texte est déclaré en unités rem ou em. Lorsqu'un utilisateur augmente sa taille de texte par défaut de 16px à 24px, les mises en page en rem s'étendent proportionnellement, tandis que les textes verrouillés en px restent figés à la dimension maquette, échouant au critère de succès WCAG 2.1 1.4.4 (Redimensionnement du texte).
De nombreux développeurs appliquent la règle html { font-size: 62.5% } pour que 1rem équivaille commodément à 10px (16px * 0,625 = 10px). Toutefois, les bibliothèques de composants modernes (telles que Radix UI, Shadcn UI ou les plugins Tailwind) calibrent leurs jetons d'espacement sur une base racine de 16px. Ce reset réduit les composants tiers non adaptés à 62,5 % de leur taille prévue, provoquant l'effondrement des marges internes (padding), le désalignement des icônes et la fragmentation du design system au sein des micro-frontends.
Alors que 1rem équivaut toujours à la taille de police de la racine du document quelle que soit la profondeur dans le DOM, 1em correspond à la taille de police du parent immédiat. Si vous imbriquez trois listes non ordonnées avec font-size: 0.875em, le premier niveau s'affiche à 14px (16 * 0,875), le deuxième descend à 12,25px (14 * 0,875), et le troisième chute à 10,7px (12,25 * 0,875). Réservez strictement l'em aux paddings et bordures internes des composants qui doivent évoluer proportionnellement à la police du composant lui-même.
Convertir une bordure de 1px en 0.0625rem (1 / 16) oblige les moteurs de rendu à calculer des fractions de pixels physiques sur les écrans dotés de ratios de pixels non entiers (tels que 1,25x ou 2,75x sur Android). Selon le niveau de zoom, 0.0625rem est tronqué à 0 pixel physique par l'arrondi sous-pixel, faisant disparaître les bordures de tableau et les contours de boutons. Conservez toujours les filets fins et séparateurs explicitement en 1px (ou via border-width: 1px) plutôt que de les convertir en rem.
Ce problème survient lorsque la largeur minimale du viewport est supérieure à la largeur maximale, ou lorsque la taille de police minimale excède la taille maximale. Des données inversées génèrent une pente négative ((minFont - maxFont) / deltaVw), ce qui rétrécit le texte au fur et à mesure que l'écran s'élargit. Pour y remédier, appliquez une validation stricte des entrées en vérifiant que minViewport < maxViewport et minFontSize <= maxFontSize avant d'évaluer l'équation d'interpolation linéaire.
La spécification W3C CSS Media Queries Level 4 impose que les unités relatives dans les media queries (@media (min-width: 40rem)) soient toujours résolues par rapport à la taille par défaut initiale du navigateur (16px), ignorant totalement les déclarations personnalisées sur l'élément html (comme 62.5% ou 10px). Une règle @media (min-width: 40rem) se déclenchera invariablement à 640px (40 * 16px), et jamais à 400px (40 * 10px). Écrivez vos media queries en rem calibrés exclusivement sur le standard de 16px.
Déclarer des classes Tailwind arbitraires comme text-[0.9375rem] (15px) ou h-[2.1875rem] (35px) peut engendrer des écarts d'arrondi de 0,5px entre Chromium (Blink) et Safari (WebKit), créant des décalages visuels de 1px dans les conteneurs flex. Résolvez ce comportement en privilégiant les incréments standard de 4px de Tailwind (ex. text-sm pour 14px ou text-base pour 16px) ou en appliquant box-sizing: border-box associé à flex-shrink: 0 sur les conteneurs.
Pour convertir des pixels (PX) en REM en CSS, divisez la valeur en pixels ciblée par la taille de police racine (qui est de 16px par défaut sur tous les navigateurs modernes) : REM = PX / BasePX. Par exemple, 24px divisé par 16px donne 1.5rem (24 / 16 = 1,5). Inversement, pour convertir des REM en PX, multipliez la valeur REM par la base : PX = REM * BasePX (1.5rem * 16 = 24px).
16px équivaut exactement à 1.000rem selon le standard W3C avec la taille de police par défaut du navigateur de 16px. Puisque 16 divisé par 16 est égal à 1, 1rem constitue la taille de police de référence pour le corps de texte, les paragraphes et les champs de formulaire standard en développement web.
L'utilisation du REM au lieu du PX est essentielle pour l'accessibilité : lorsque des utilisateurs malvoyants modifient la taille de police par défaut de leur navigateur, toute la typographie et les espacements définis en REM s'adaptent proportionnellement, préservant la lisibilité et l'harmonie de l'interface. À l'inverse, des valeurs codées en dur en PX figent le texte à une taille absolue, violant les critères d'accessibilité WCAG 1.4.4 et provoquant des troncatures ou des textes illisibles.
Pour calculer CSS clamp(), définissez votre taille de police minimale (ex. 16px pour un viewport de 375px) et maximale (ex. 24px pour un viewport de 1440px). La pente linéaire est (24 - 16) / (1440 - 375) = 8 / 1065 ≈ 0,007512. L'ordonnée à l'origine vaut -375 * 0,007512 + 16 ≈ 13,183px (0,8239rem). La valeur intermédiaire idéale est 0.8239rem + 0.7512vw, ce qui génère la formule CSS de production : clamp(1rem, 0.8239rem + 0.7512vw, 1.5rem).
La différence fondamentale réside dans leur élément de référence : le REM (Root EM) est toujours relatif à la taille de police de l'élément racine <html> (16px par défaut), tandis que l'EM est relatif à la taille de police de son élément parent direct. Les unités EM imbriquées se multiplient en cascade le long de l'arbre DOM (ex. 0.8em dans 0.8em devient 0.64em), alors que les valeurs en REM demeurent prévisibles et constantes quel que soit le niveau d'imbrication des composants.
La conversion d'une bordure de 1px en 0.0625rem produit des imprécisions de calcul sur les écrans mobiles aux ratios de pixels non entiers (ex. 2,625x). Lors des cycles de rendu de WebKit mobile, 0.0625rem est fréquemment arrondi à 0 pixel physique, provoquant la disparition pure et simple des bordures de boutons et des filets de séparation. Pour les bordures fines d'un pixel, il est recommandé de toujours conserver une valeur explicite en 1px plutôt qu'en REM.
Vérifiez les codes d'état HTTP, testez les chaînes de redirection et analysez les en-têtes de réponse. Diagnostiquez les erreurs 1xx à 5xx, la conformité RFC et l'impact SEO.
Testez, déboguez et optimisez vos expressions régulières en temps réel. Analysez les correspondances de motifs, les groupes de capture, l'arbre syntaxique et les substitutions.
Calculez masques de sous-réseau IPv4, plages CIDR, hôtes utilisables et adresses de diffusion. Inspection binaire bit à bit, découpage VLSM et règles VPC cloud.
Effectuez des additions et soustractions binaires avec calcul pas à pas des retenues, complément à deux signé, simulation de portes logiques et conversion hexadécimale en temps réel.
Testez et validez la syntaxe robots.txt selon la norme RFC 9309. Vérifiez les autorisations de crawl par User-Agent, déboguez les chemins Disallow et inspectez les sitemaps.
Convertissez du Markdown en code HTML propre et optimisé pour la production en temps réel. Tableaux GFM, coloration syntaxique, assainissement XSS et export complet.