CSS単位コンバータ

設定可能なコンテキストでpx、rem、em、vw、vh、pt、cm、mm、in、%間で変換します。

コンテキスト設定

変換

結果

CSS単位リファレンス

絶対単位

相対単位

remとemはいつ使い分けるべきですか?

remは一貫したサイジング(マージン、パディング、フォントサイズ)に使用 · 常にルートを参照します。emは、コンテキストに適応するネストされたコンポーネントなど、親に対する相対サイジングが必要な場合に使用します。

なぜpxは常に物理ピクセル1つに等しくないのですか?

CSSのpxは、腕の長さで1/96インチとして定義された「リファレンスピクセル」です。高密度(HiDPI)ディスプレイでは、1つのCSS pxが2〜3個の物理ピクセルに対応する場合があります。

CSSリファレンスピクセル：すべての絶対単位の要石

CSSの絶対単位（in・cm・mm・Q・pt・pc・px）はCSSリファレンスピクセルを基準としている。W3C CSS Values and Units Module Level 3では「デバイスのピクセル密度が96dpiで閲覧距離が腕の長さのデバイス上での1ピクセルの視角」と定義している。腕の長さを約28インチとした場合、この視角は約0.0213°で、標準的な視聴距離での物理的な画面幅に換算すると約0.26mmに相当する。同じ視角でも12フィート離れると約1.3mmになることを仕様書は示しており、これがプロジェクターやテレビのピクセルが物理的に大きくても1CSSピクセルとして数えられる理由だ。

画面に対して、仕様はCSSの1in = 96 pxを実際のインチから導出するのではなく定義している。つまり上の表の換算は正確であり、ディスプレイのDPIには依存しない：12ptは常に16px、1pcは常に16px、1mmは常に約3.78pxだ。高DPIディスプレイ（Retina・4K）ではOSが各CSSピクセルを視角に最も近いデバイスピクセルにマッピングする。典型的にはRetina MacBookでCSSピクセル1つあたりデバイスピクセル2、iPhone Proで3、150%スケーリングのWindowsデスクトップで1.5だ。Retinaスクリーンでの鮮明な1pxボーダーは2デバイスピクセルを使用する。

フォント相対単位

これらはインチなどの物理単位ではなくタイポグラフィを基準に解決される。アクセシブルでスケーラブルなレイアウトの礎石だ。

emは基礎をなす単位であり、歴史的な深みは驚くほどで、CSSより約500年古い。活版印刷（グーテンベルク以降、1450年頃）では「emクワッド」は活字の高さと等しい幅を持つ金属の正方形のブロックで、歴史的には大文字Mの幅に近似していた。CSSはこの抽象概念を借用している：1emは現在の要素の計算済みfont-sizeに等しい。有名な落とし穴は入れ子のfont-size: 1.2em宣言が掛け合わされることだ。1.2emの親の中にある1.2emの子は祖先要素の1.44×でレンダリングされる。

rem（「ルートem」）はこの複利問題を解決するためにCSS3で追加された。1remはルートの<html>要素のfont-sizeに等しく、親の入れ子の影響を受けない。ブラウザはユーザーが上書きしない限りルートをデフォルトで16 pxとするため、デフォルト条件では1rem = 16pxとなる。remは2010年のSafari 4.1とFirefox 3.6、2011年3月のIE9でサポートされた。IE8はサポートしなかったため、2014年頃まではpxフォールバックが強制された。

新しいフォント相対単位（CSS Values 4）にはch（現在のフォントの「0」文字の幅。max-width: 60chや66chのような行の長さ最大幅に便利で、タイポグラフィ的に理想的な45〜75文字の読書範囲に収まる）、ex（フォントのx高）、cap（大文字の高さ）、ic（CJK「水」字の送り幅）、lh / rlh（要素の計算済み行高 / ルートの行高。垂直リズムに有用）がある。

ビューポートパーセンテージ単位（とモバイルのアドレスバー問題）

古典的な4つ、vw・vh・vmin・vmaxは、それぞれビューポート幅の1%・ビューポート高さの1%・両者の小さい方の1%・大きい方の1%を表す。1920 × 1080の場合：1vw = 19.2px、1vh = 10.8px。

100vhはモバイルで長年の問題だった。iOS SafariとChrome Mobileはスクロール時に収縮するURLバーを表示するためだ。ブラウザは選択を迫られた：100vhを短いビューポート（URLバー表示時、スクロール後にコンテンツが切れる）に等しくするか、長いビューポート（URLバー非表示時、初回ペイントで大きな空白ができる）に等しくするか。iOS Safariは長い方を採用したため、「なぜヒーローセクションが画面より大きいのか」という問いを開発者が何年もデバッグし続けた。

Interop 2022の取り組み（Apple・Google・Igalia・Microsoft・Mozillaなど）は2022年3月にこの問題を解決するための新しいビューポートバリアントを追加した：

実践的なレシピ：iOSで切れないようにするためにヒーローセクションにmin-height: 100svhを使う。またはフルスクリーンモーダルにheight: 100dvhを使う。Safariが最初にサポートした（15.4、2022年3月）。Firefox 101（2022年5月）、ChromeとEdge 108（2022年12月）が続いた。現在グローバルサポートは広く普及している。

コンテナクエリ単位

新しいファミリー、cqw・cqh・cqi・cqb・cqmin・cqmaxは、ビューポートではなくコンテナを基準に要素のサイズを設定できる。同じコンポーネントがサイドバーでは300px幅、メインカラムでは900px幅で表示されるようなコンポーネント駆動設計に不可欠だ。この単位はcontainer-typeが設定された最も近い祖先コンテナに対して評価される。適格なコンテナが存在しない場合は、仕様によりその軸のスモールビューポート単位にフォールバックする。コンテナクエリ（および単位）は2022年のChromium 105、2022年9月のSafari 16、2023年2月のFirefox 110でリリースされ、2023年にBaselineとして新たに利用可能になった。

パーセンテージ、そしてそれが実は長さでない理由

パーセンテージは厳密には長さの単位ではなく、文脈に応じて解決される別の値の型だ：

このような文脈依存の解決方法のため、%は親の寸法を知らなければpxに単純に変換できない。上のコンバーターはそれを明示的に入力させている。

実践的なガイダンス：何をいつ使うか

clamp()によるフルードタイポグラフィ

clamp(MIN, PREFERRED, MAX)は下限と上限で制約された優先値を返す。古典的なフルード型パターンはremの床と天井にvwドリブンのスケーリングミドルを組み合わせる：

h1 { font-size: clamp(1.8rem, 1.2rem + 2.5vw, 3rem); }

ミドル項はビューポートに合わせてリニアにスケールし、remベースの下限と上限が極端なサイズを防ぎ、ユーザーのフォントスケーリングを保持する。clamp()は2020年7月（Chrome 79・Firefox 75・Safari 13.1）にBaselineとして広く利用可能になった。Utopia（utopia.fyi）やfluid-type-scale.comのようなツールはビューポートの最小 / 最大幅・フォントサイズの最小 / 最大・モジュラースケール比率（1.2・1.25・1.333・1.5・黄金比）を入力すると、コピペ可能なCSSを出力する。

アクセシビリティ、WCAG SC 1.4.4 テキストのリサイズ

規格はコンテンツや機能を失わずにテキストを元のサイズの200%まで拡大できることを要求している。特定の単位を義務付けてはいないが、十分な達成方法には「コンテンツ内の他の計測値に対して相対的な計測値を使用すること」が含まれており、相対単位（em・rem・%）はコンプライアンスを容易にする。ピクセルのみのレイアウトはブラウザズームで合格できるが、より脆弱だ。精神的なテスト：ユーザーがデフォルトのテキストサイズを拡大したときにこれはスケールすべきか？　はいなら、remを使う。ボーダー・装飾パディング・純粋な装飾はpxのままで構わない。

さらなる質問

なぜ画面上の1inは本当のインチではないのか？

CSSの仕様が絶対単位を物理的なインチではなく視角の基準に固定しているためだ。CSS 1inはちょうど96CSSピクセルと定義されており、ブラウザはそれを標準的な視聴距離での基準に最も近いデバイスピクセルにマッピングする。ほとんどのモニターでは実際のインチに近い値になるが、部屋の反対側から見るテレビでは物理的に大きくなり、膝の上にある高DPIラップトップではわずかに小さくなるかもしれない。実際の物理的な測定には画面に定規を当てること。

「62.5%のトリック」とは何か？

よく使われるパターン：html { font-size: 62.5%; }。62.5% × 16 = 10なので1rem = 10pxとなり、暗算が便利だ（1.6rem = 16px、2.4rem = 24px）。議論はある。反対派はユーザーのデフォルトフォントサイズを上書きし、アクセシビリティ的にやや不親切だと主張する。多くのモダンなチームはユーザー上書きを明示的に保持した比率を選ぶ（例：カスケードがユーザーのデフォルトを尊重するようにremでbodyのfont-sizeを設定する）。

vwとcqwはどちらを使うべきか？

サイズがビューポートを追跡すべき場合（全幅ヒーローテキスト・フルスクリーンモーダル）はvwを使う。サイズがコンポーネントのコンテナを追跡すべき場合はcqwを使う。例えば、カードタイトルはメインカラムでは大きく、サイドバーでは小さくなるべきで、ビューポートサイズに関係なく。コンテナクエリ単位は2022〜2023年にリリースされ、単一コンポーネントにメディアクエリ駆動のフォントスケールを適用しようとする場面ではほぼ常に正しい答えだ。

@mediaクエリのdpiとdppxの違いは何か？

どちらも解像度を表す。dppxは「CSSピクセルあたりのドット数」を意味し、CSSが1インチを96pxと定義しているため1dppx = 96dpiとなる。@media (min-resolution: 2dppx)はCSSピクセル1つが少なくとも2デバイスピクセルでレンダリングされるRetinaクラスのディスプレイを対象とする。dpiとCSSインチの混乱を避けられるため、一般的にdppxの使用が推奨される。

サーバーに何か送信されますか？

いいえ。変換はブラウザのJavaScriptによる単純な算術演算で、ローカルで実行される。入力に関する情報は一切送信されない。ページは一度読み込まれればオフラインでも動作する。

関連ツール

無料PXからREMへの変換 CSS Border Radiusジェネレーター オンライン無料単位変換