CSS Einheiten Konverter
Konvertieren Sie zwischen px, rem, em, vw, vh, pt, cm, mm, in und % mit konfigurierbarem Kontext.
Kontext-Einstellungen
Konvertieren
Ergebnisse
CSS-Einheiten-Referenz
Absolute Einheiten
- px · Pixel (1/96 Zoll)
- pt · Punkt (1/72 Zoll)
- cm · Zentimeter
- mm · Millimeter
- in · Zoll
Relative Einheiten
- rem · relativ zur Wurzel-Schriftgröße
- em · relativ zur Eltern-Schriftgröße
- vw · 1 % der Viewport-Breite
- vh · 1 % der Viewport-Höhe
- vmin · 1 % der kleineren Viewport-Dimension
- vmax · 1 % der größeren Viewport-Dimension
- % · Prozent vom Elternelement
Wann soll ich rem statt em verwenden?
Nutzen Sie rem für konsistente Größen (Margins, Padding, Schriftgrößen) · es bezieht sich immer auf die Wurzel. Nutzen Sie em, wenn die Größe relativ zum Elternelement sein soll, etwa bei verschachtelten Komponenten, die sich am Kontext skalieren.
Warum ist px nicht immer gleich einem physischen Pixel?
Das CSS-px ist ein „Referenzpixel", definiert als 1/96 Zoll bei Armlängen-Distanz. Auf hochauflösenden Displays kann ein CSS-px 2 oder 3 physischen Pixeln entsprechen.
Das CSS-Referenzpixel, der Schlussstein jeder absoluten Einheit
Absolute CSS-Einheiten (in, cm, mm, Q, pt, pc, px) sind am CSS-Referenzpixel verankert. Das W3C CSS Values and Units Module Level 3 definiert es als „den Sehwinkel eines Pixels auf einem Gerät mit einer Gerätepixeldichte von 96 dpi und einem Abstand vom Betrachter von einer Armlänge“. Bei einer Armlänge von etwa 28 Zoll beträgt dieser Sehwinkel rund 0,0213°, entsprechend etwa 0,26 mm physischer Bildschirmbreite bei typischem Betrachtungsabstand, und die Spezifikation veranschaulicht, dass derselbe Sehwinkel bei 12 Fuß auf rund 1,3 mm hinausläuft, weshalb Projektor- und Fernsehpixel physisch größer sein können, aber dennoch jeweils als ein CSS-Pixel zählen.
Für Bildschirme definiert die Spezifikation CSS 1in = 96 px, anstatt von echten Bildschirmzoll abzuleiten. Das bedeutet, dass die Umrechnungen in der Tabelle oben exakt sind und nicht von der Display-DPI abhängen: 12 pt sind immer 16 px, 1 pc ist immer 16 px, 1 mm ist immer etwa 3,78 px. Auf einem High-DPI-Display (Retina, 4K) ordnet das Betriebssystem jedes CSS-Pixel denjenigen Gerätepixeln zu, die den Sehwinkel am besten annähern, typischerweise 2 Gerätepixel pro CSS-Pixel auf einem Retina-MacBook, 3 auf einem iPhone Pro, 1,5 auf einem Windows-Desktop bei 150 % Skalierung. Ein scharfer 1px-Rahmen auf einem Retina-Bildschirm benötigt 2 Gerätepixel.
Schriftrelative Einheiten
Diese beziehen sich auf die Typografie statt auf physische Zoll. Sie sind das Fundament barrierefreier, skalierbarer Layouts.
em ist der Eckpfeiler, mit überraschend tiefer Geschichte: Es ist rund 500 Jahre älter als CSS. Im Bleisatz (nach Gutenberg, ca. 1450) war das „Geviert“ ein quadratischer Metallblock, dessen Breite der Höhe des Schriftkegels entsprach, historisch annähernd die Breite des großen M. CSS übernimmt die Abstraktion: 1em entspricht der berechneten Schriftgröße des aktuellen Elements. Der berühmte Fallstrick ist, dass sich verschachtelte font-size: 1.2em-Deklarationen multiplizieren: Ein Kind mit 1.2em in einem Elternelement mit 1.2em wird mit dem 1,44-fachen des Großelternelements dargestellt.
rem („root em“) wurde in CSS3 hinzugefügt, um genau dieses Aufsummierungsproblem zu lösen. 1rem entspricht der Schriftgröße des Wurzelelements <html>, unbeeinflusst von der Verschachtelung der Elternelemente. Browser setzen die Wurzel standardmäßig auf 16 px, sofern der Nutzer dies nicht überschreibt, also gilt unter Standardbedingungen 1rem = 16px. rem kam 2010 in Safari 4.1 und Firefox 3.6, in IE9 im März 2011; IE8 unterstützte es nie, was bis etwa 2014 px-Fallbacks erzwang.
Zu den neueren schriftrelativen Einheiten (CSS Values 4) gehören ch (die Breite des Zeichens „0“ in der aktuellen Schrift, nützlich für Zeilenlängen-Maximalbreiten wie max-width: 60ch oder 66ch, die im typografisch idealen Lesebereich von 45 bis 75 Zeichen liegen), ex (x-Höhe der Schrift), cap (Versalhöhe), ic (Dickte des CJK-Ideogramms 水) und lh / rlh (die berechnete Zeilenhöhe des Elements / der Wurzel, nützlich für den vertikalen Rhythmus).
Viewport-Prozent-Einheiten (und das Problem der mobilen Adressleiste)
Die klassischen vier, vw, vh, vmin, vmax: stehen für 1 % der Viewport-Breite, 1 % der Viewport-Höhe, 1 % des kleineren der beiden Werte und 1 % des größeren. Bei 1920 × 1080: 1vw = 19.2px, 1vh = 10.8px.
100vh war auf Mobilgeräten lange ein Ärgernis, weil sowohl iOS Safari als auch Chrome Mobile eine Adressleiste anzeigen, die sich beim Scrollen einzieht. Browser mussten sich entscheiden: 100vh entweder dem kurzen Viewport gleichsetzen (Adressleiste sichtbar, Inhalt wird nach dem Scrollen abgeschnitten) oder dem hohen (Adressleiste ausgeblendet, große Leerfläche beim ersten Rendern). iOS Safari wählte das hohe Verhalten und ließ Entwickler jahrelang darüber rätseln: „warum ist mein Hero-Bereich höher als der Bildschirm?“.
Die Interop-2022-Initiative (Apple, Google, Igalia, Microsoft, Mozilla und andere) fügte im März 2022 neue Viewport-Varianten hinzu, um das zu beheben:
- Kleiner Viewport (
svw/svh/svmin/svmax), nimmt an, dass die Browser-Oberfläche vollständig ausgefahren ist; der kleinstmögliche Viewport. Stabil beim ersten Rendern. - Großer Viewport (
lvw/lvh/ usw.), nimmt an, dass die Browser-Oberfläche vollständig eingezogen ist; der größtmögliche Viewport. - Dynamischer Viewport (
dvw/dvh/ usw.), aktualisiert sich live, während die Oberfläche schrumpft und sich ausdehnt. Beste Passung, kann aber während des Scrollens Neuzeichnungen verursachen.
Praktisches Rezept: min-height: 100svh auf einem Hero-Bereich, damit er auf iOS nicht abgeschnitten wird, oder height: 100dvh auf einem Vollbild-Modal. Safari lieferte als Erster Unterstützung (15.4, März 2022); Firefox 101 (Mai 2022); Chrome und Edge 108 (Dezember 2022). Die globale Unterstützung ist inzwischen weit verbreitet.
Container-Query-Einheiten
Eine neuere Familie, cqw, cqh, cqi, cqb, cqmin, cqmax: lässt ein Element sich anhand seines Containers statt des Viewports dimensionieren. Unverzichtbar für komponentenbasiertes Design, bei dem dieselbe Komponente in einer Seitenleiste 300 px breit und in einer Hauptspalte 900 px breit erscheinen kann. Die Einheit wird gegenüber dem nächstgelegenen übergeordneten Container mit gesetztem container-type ausgewertet; existiert kein geeigneter Container, greift die Spezifikation auf dieser Achse auf die Kleiner-Viewport-Einheit zurück. Container-Queries (und -Einheiten) kamen 2022 in Chromium 105, im September 2022 in Safari 16 und im Februar 2023 in Firefox 110 und wurden 2023 als Baseline neu verfügbar.
Prozentangaben, und warum sie nicht wirklich eine Länge sind
Prozentangaben sind an sich keine Längeneinheit, sie sind ein eigener Werttyp, der sich kontextabhängig auflöst:
- Bei
width/height: Prozentsatz der Inline-/Block-Größe des Elternelements. - Bei
font-size: Prozentsatz der berechneten Schriftgröße des Elternelements. - Bei
line-height: Prozentsatz der eigenen Schriftgröße des Elements. - Bei
marginundpaddingauf allen vier Seiten: Prozentsatz der Inline-Größe des Elternelements (also der Breite). Das ist die Quelle der berühmten Überraschung „vertikaler Margin in % entspricht dem horizontalen“. - Bei
transform: translate(): Prozentsatz der eigenen Abmessungen des Elements.
Wegen dieser kontextabhängigen Auflösung lässt sich % nicht einfach in px umrechnen, ohne die Abmessung des Elternelements zu kennen; der Umrechner oben fragt sie ausdrücklich ab.
Praktische Hinweise: wann was zu verwenden ist
- Verwenden Sie rem für
font-size. Es respektiert die Standard-Schrifteinstellung des Browsers des Nutzers, ein echter Gewinn für die Barrierefreiheit, weil sehbehinderte Nutzer global statt pro Website skalieren können. - Verwenden Sie em für komponenteninterne Proportionen: Icon-Größen, die zum Schaltflächentext passen sollen, Innenabstand in einer Schaltfläche, der mit dem Text skaliert.
- Vermeiden Sie px bei
font-size. Browser-Zoom hilft, aber nur pro Website; rem respektiert außerdem die vom Nutzer überschriebene Standard-Schriftgröße. - px ist in Ordnung für Rahmen, scharfe dekorative Elemente und Schatten, bei denen die physische Stärke wichtiger ist als die Skalierung.
- % für fluide Layouts, bei denen Kinder ihr Elternelement ausfüllen müssen.
- vw / vh für Hero-Bereiche, randlose Hintergründe und Modals: aber greifen Sie zu
svhoderdvhstattvhbei allem, was den unteren Rand mobiler Bildschirme berührt. - vmin für Elemente mit quadratischem Seitenverhältnis (Avatare, Splash-Screens), damit sie auf beiden Achsen hineinpassen.
- ch für Zeilenlängen-Maximalbreiten bei Fließtext:
max-width: 60choder66chliegt im idealen Lesebereich.
Fluide Typografie mit clamp()
clamp(MIN, PREFERRED, MAX) gibt den bevorzugten Wert zurück, begrenzt durch Unter- und Obergrenze. Das klassische Fluid-Type-Muster kombiniert eine Unter- und Obergrenze auf rem-Basis mit einer vw-getriebenen Skalierung in der Mitte:
h1 { font-size: clamp(1.8rem, 1.2rem + 2.5vw, 3rem); }
Der mittlere Term skaliert linear mit dem Viewport, während die rem-basierte Unter- und Obergrenze extreme Größen verhindern und die Schriftskalierung des Nutzers bewahren. clamp() erreichte im Juli 2020 den Baseline-Status „weithin verfügbar“ (Chrome 79, Firefox 75, Safari 13.1). Werkzeuge wie Utopia (utopia.fyi) und fluid-type-scale.com nehmen minimale/maximale Viewport-Breiten, minimale/maximale Schriftgrößen und ein modulares Skalenverhältnis (1,2, 1,25, 1,333, 1,5, Goldener Schnitt) entgegen und geben einfügefertige Deklarationen aus.
Barrierefreiheit, WCAG SC 1.4.4 Textgröße ändern
Der Standard verlangt, dass Text auf 200 % der Originalgröße vergrößerbar ist, ohne Verlust von Inhalt oder Funktionalität. Er schreibt keine bestimmte Einheit vor, aber zu den aufgeführten ausreichenden Techniken gehört „die Verwendung von Maßen, die relativ zu anderen Maßen im Inhalt sind“; relative Einheiten (em, rem, %) erleichtern die Einhaltung; reine Pixel-Layouts können über den Browser-Zoom bestehen, sind aber fragiler. Der gedankliche Test: Sollte dies skalieren, wenn der Nutzer seine Standard-Textgröße vergrößert? Falls ja, verwenden Sie rem. Rahmen, dekorativer Innenabstand und reine Dekoration können px bleiben.
Weitere Fragen
Warum ist 1in auf meinem Bildschirm nicht wirklich ein Zoll?
Weil die CSS-Spezifikation absolute Einheiten an einer Referenz des Sehwinkels verankert statt an physischen Zoll. Ein CSS-1in ist als exakt 96 CSS-Pixel definiert, die der Browser denjenigen Gerätepixeln zuordnet, die die Referenz bei typischem Betrachtungsabstand am besten annähern. Auf den meisten Monitoren kommt das einem echten Zoll nahe, aber auf einem quer durch den Raum betrachteten Fernseher ist es physisch größer, und auf einem High-DPI-Laptop auf Ihrem Schoß könnte es etwas kleiner sein. Für echte physische Messung legen Sie ein Lineal an den Bildschirm.
Was ist der „62,5-%-Trick“, den manche manchmal erwähnen?
Ein weit verbreitetes Muster: html { font-size: 62.5%; }. Weil 62,5 % × 16 = 10 ist, ergibt das 1rem = 10px: praktisch für Kopfrechnen (1.6rem = 16px, 2.4rem = 24px). Es ist umstritten; Gegner argumentieren, es überschreibe die vom Nutzer bevorzugte Standard-Schriftgröße und sei für die Barrierefreiheit leicht nutzerfeindlich. Viele moderne Teams wählen ein Verhältnis, bei dem die Überschreibung durch den Nutzer ausdrücklich erhalten bleibt (z. B. indem die Schriftgröße des body in rem gesetzt wird, sodass die Kaskade den Standard des Nutzers respektiert).
Wann sollte ich vw statt cqw verwenden?
Verwenden Sie vw, wenn die Größe dem Viewport folgen soll (randloser Hero-Text, Vollbild-Modals). Verwenden Sie cqw, wenn die Größe dem Container der Komponente folgen soll: zum Beispiel ein Kartentitel, der größer ist, wenn die Karte in der Hauptspalte steht, und kleiner, wenn sie in einer Seitenleiste steht, unabhängig von der Viewport-Größe. Container-Query-Einheiten kamen 2022 bis 2023 und sind fast immer dann die richtige Antwort, wenn Sie sonst zu einer per Media-Query gesteuerten Schriftskalierung für eine einzelne Komponente greifen würden.
Was ist der Unterschied zwischen dpi und dppx in @media-Queries?
Beide drücken die Auflösung aus. dppx bedeutet „Punkte pro CSS-Pixel“, 1dppx = 96dpi, da CSS 96 px pro Zoll definiert. @media (min-resolution: 2dppx) zielt auf Displays der Retina-Klasse, bei denen jedes CSS-Pixel mit mindestens 2 Gerätepixeln gerendert wird. dppx zu verwenden wird allgemein bevorzugt, weil es die Verwechslung zwischen dpi und CSS-Zoll vermeidet.
Werden Daten an einen Server gesendet?
Nein. Die Umrechnungen sind einfache JavaScript-Arithmetik, die lokal in Ihrem Browser läuft. Nichts von Ihren Eingaben wird irgendwohin gesendet; die Seite funktioniert offline, sobald sie geladen ist.