無料PXからREMへの変換
設定可能なベースフォントサイズで、ピクセルとremを相互変換します。
参照表
| PX | REM |
|---|
仕組み
REMは「root em」を意味し、ルート要素のフォントサイズを基準としています。デフォルトでは、ブラウザは16 pxを使用します。式はシンプルです: rem = px ÷ ベースとpx = rem × ベース。プロジェクトが異なるルートを使用する場合は、上のベースサイズを変更してください。
よくある質問
なぜpxの代わりにremを使うのですか?
REM単位はユーザーのブラウザのフォントサイズ設定に適応し、アクセシビリティを向上させます。ユーザーがデフォルトのフォントサイズを大きくすると、固定されているピクセル値とは異なり、remベースのレイアウトは自動的に調整されます。
emとremの違いは?
EMは親要素のフォントサイズを基準としており、ネストされた要素で複合する可能性があります。REMは常にルート要素(<html>)のフォントサイズを基準としているため、より予測可能です。
どのベースを使うべきですか?
ほとんどのプロジェクトは16 pxのブラウザのデフォルト値を使用します。一部の開発者は、より簡単な計算のためにhtml { font-size: 62.5%; }(10 px)を設定します。プロジェクトに対して定義されたルートフォントサイズを使用してください。
remとは実際には何か
「Rem」はルートemの略だ。W3C CSS Values Level 3仕様では「ルート要素のfont-sizeの計算値に等しい」、すなわち<html>要素の値として定義されている。ブラウザはオーバーライドされない限り<html>を16pxにデフォルト設定するため、バニラなページでは1rem = 16px、0.5rem = 8px、1.5rem = 24px、2rem = 32pxとなる。
スタイルシートがhtml { font-size: 20px }と宣言すれば、文書の残り全体で1rem = 20pxになる。ユーザーがブラウザのデフォルトを24pxに引き上げた場合（視力の弱いユーザーに多い調整）、スタイルシートのオーバーライドがなくても1rem = 24pxになる。これがremのアクセシビリティケース全体を一文で表したものだ。
remが重要な理由：アクセシビリティケース
ブラウザはユーザーに2つの異なるスケーリングメカニズムを提供しており、それぞれユニットに対して異なる動作をする：
- ブラウザズーム（Cmd/Ctrl + またはピンチ）はビューポート全体を均一にスケーリングする。200%ズームの16px要素は100%ズームの32px要素と同じ画面スペースを占める。
pxとremはどちらもズーム下で同じようにスケーリングするため、ズーム単体ではremを正当化しない。 - ブラウザのデフォルトフォントサイズ設定：ブラウザ設定の奥にある（Firefoxは
about:preferences、Chromeの「フォントのカスタマイズ」）。ユーザーが「デフォルトのフォントサイズ」を16から24に変更すると（視力の弱いユーザーに多い）、<html>要素の計算値が24pxになる。すべてのremの値は自動的に1.5×スケーリングされ、固定pxの値はまったく変わらない。
これがremで構築されたレイアウトはユーザーのアクセシビリティ設定を尊重し、pxで構築されたレイアウトはそうでない理由だ。WCAG 2.2 達成基準 1.4.4（テキストのリサイズ、レベルAA）はテキストをコンテンツや機能の喪失なしに少なくとも200%まで拡大できることを要求している。ブラウザズーム単体では技術的にこれをパスするが、remベースのレイアウトはデフォルトフォントサイズのメカニズム（実際に視力の弱いユーザーが日々調整するもの）を尊重するため、より明瞭にパスする。
remのきっかけとなったemの複合問題
rem以前、CSSでスケーラブルなタイポグラフィを実現する唯一の方法はルートではなく親要素のfont-sizeに相対的なemだった。古典的な問題：emベースのフォントサイズを持つネスト要素は複合する。
.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× */3重ネストのリストはボディサイズのほぼ2倍に膨れ上がり、これはほぼ意図されない。remはルートに毎回アンカーすることでこれを解決する：1.2remの3つのネスト要素は、ネストの深さに関わらずすべて19.2pxだ。これが多くの最新スタイルシートがremにfont-sizeを使い、コンポーネント内部の比率（ボタンのテキストに合わせるべきアイコンサイズ、ラベルと一緒にスケールするボタン内のパディング）にemを予約している理由だ。
62.5%トリック：便利な計算、アクセシビリティへの疑問
Jonathan Snookが2011年5月の記事で広めたパターン：html { font-size: 62.5% }と設定する。62.5% × 16 = 10なので、デフォルトでは1rem = 10pxとなり、便利な暗算ができる。1.6rem = 16px、2.4rem = 24px、4.8rem = 48px。デザイナーは各値から「16で割る」という演算を取り除けるため気に入った。
アクセシビリティの批判（当時提起され、後の文献で強化された）：ルートfont-sizeを62.5%に設定すると、ユーザーがブラウザ設定で選択した値が事実上縮小される。視力の弱いユーザーがデフォルトを24pxに設定した場合、ボディテキストが15pxになってしまい、remを使う意味が失われる。現代の反論は、ルートを62.5%に設定しつつボディのfont-sizeを1.6remと明示的に宣言する（16pxに戻す）ことで、ユーザーのオーバーライドが正しくカスケードするというものだ。このトリックをまったく使わずにやや不格好な計算に甘んじるチームも多い。
remとpxのどちらを使うか：Comeauの考え方
Josh W. Comeauの記事「px or rem?」（2022年5月、2025年5月更新）がこの決断に最も有用な単一質問のヒューリスティックを提供している。質問：「この値はユーザーがブラウザのデフォルトフォントサイズを大きくしたときにスケールアップすべきか？」そうならremを、そうでなければpxを使う。
そのテストによると：
- remを使う場面：font-size、縦方向のマージン/パディング（タイプリズムに紐付いているもの）、ボタン幅などコンテンツ形状に合わせたコンテナ、行長のmax-width、ブレークポイント（視力の弱いユーザーに適した拡大サイズでレイアウトが切り替わるよう）。
- pxを使う場面：ボーダー（1pxのヘアラインはヘアラインのまま）、水平パディング/装飾、シャドウ半径、固定ピクセルの意図がある画像サイズ、細かいアイコンサイズ。
単一質問テストはコードベースの何千もの決断を通じて一貫した答えを生み出す。これが本当の勝利であり、その結果のスタイルシートはズームとフォントサイズのカスタマイズ両方においてユーザーが期待する動作をする。
Tailwind CSS 4のrem全面採用
Tailwind CSS v4.0（2025年1月）は完全なremベースのデフォルトスケールを搭載した。すべてのタイポグラフィトークン（text-xs 0.75remからtext-9xl 8rem）とすべてのスペーシングトークン（p-1 0.25rem、p-4 1rem、m-8 2rem）が最初からrem単位になっている。Tailwind 4はブラウザのデフォルト16pxを<html>ルートに意図的に残している（62.5%トリックを適用しない）ため、ユーザーのアクセシビリティ設定がクリーンにカスケードする。数千万のプロジェクトがデフォルトでremベースのデザインシステムを使用するようになり、エコシステムが収束したことの最強の証拠だ。
デフォルト16pxルートでの変換テーブル
| ピクセル | Rem | 一般的な用途 |
|---|---|---|
| 8 px | 0.5 rem | ベースユニットの半分、小さなスペーシング |
| 12 px | 0.75 rem | キャプション、細かい文字 |
| 14 px | 0.875 rem | サブテキスト |
| 16 px | 1 rem | 本文テキストのデフォルト |
| 18 px | 1.125 rem | やや強調した本文 |
| 20 px | 1.25 rem | リードパラグラフ |
| 24 px | 1.5 rem | H4見出し；大きなUIテキスト |
| 32 px | 2 rem | H3見出し |
| 48 px | 3 rem | H2 / ヒーロー見出し |
| 64 px | 4 rem | H1 / ディスプレイ見出し |
現代のツールキットにおけるremの位置づけ
remはタイプとタイプに紐付いたスペーシングに適したデフォルトだが、すべてのレイアウト問題の答えではない。現代のツールボックスにはこれらも含まれる：
- clamp() は流体タイポグラフィに使用する。
font-size: clamp(1rem, 0.8rem + 1vw, 1.5rem)はremのフロアとシーリングをビューポート駆動のミドルで設定する。CSS単位コンバータ - ビューポートユニット（
vw、vh、モバイル向けの新しいsvh/lvh/dvh）：ビューポートと共にスケールすべきヒーローセクションやフルブリード要素に使用する。 - コンテナクエリユニット（
cqw、cqh）：同じコンポーネントが異なる幅で表示されるコンポーネント駆動のデザインに使用する。
それ以外すべて（本文テキスト、見出し、パディング、ボタン幅、ブレークポイント）にはremが最も抵抗の少ないパスで、最もアクセシビリティの高いデフォルトだ。
その他の質問
プロジェクトがデフォルト以外のベースフォントサイズを使用している場合は？
上のベースフォントサイズフィールドをプロジェクトのhtml { font-size: … }が解決する値に変更する。変換の計算はベースに関わらずrem = px ÷ baseだ。コードベースが18pxを使用する場合、32pxは1.78remになる。10px（62.5%トリック）の場合は3.2remになる。ルートfont-sizeをオーバーライドするとブラウザのデフォルトをカスタマイズしているユーザーへのアクセシビリティに影響があることに注意。62.5%トリックの議論を参照。
0.625remはなぜ正確に10pxにレンダリングされないのか？
数学的には、デフォルト16pxルートでは正確に10pxになる（0.625 × 16 = 10）。しかしブラウザはサブピクセル精度でレンダリングし、最終値を整数デバイスピクセルにスナップすることがあるため、0.625remのボーダーはモニターのDPRによってはハードコードされた10pxのボーダーとわずかに違って見えることがある。ピクセルパーフェクトな1ピクセルのヘアラインには1pxを直接使う。それ以外はremベースの値で問題ない。
同じスタイルシートでremとpxを混在させられるか？
はい、そうすべきだ。フォントサイズ設定でスケールすべきもの（タイポグラフィ、縦方向のリズム、ブレークポイント）にはremを、そうでないもの（ボーダー、アイコンの詳細、装飾的なシャドウ）にはpxを使う。Comeauの「これはスケールすべきか？」という質問が実用的なフィルターであり、答えはほぼ毎回どちらかのユニットにきれいにマッピングされる。
ビルドツールはpxをremに自動変換するか？
はい。postcss-pxtoremやpostcss-rem-to-responsive-pixelなどのPostCSSプラグインは、設定可能なしきい値（例：「≥ 12pxのものをすべて変換」）でビルドステップ中に作成したCSSのpx値をremに書き換えられる。既存のpx主体のコードベースの移行に役立つ。このページのようなライブコンバーターは、手作業での計算、デザイン仕様の参照、計算を手で学ぶ際に役立つ。
何かサーバーに送信されるか？
いいえ。変換は1回の割り算で、ブラウザ内でローカルに実行される純粋なJavaScriptの演算だ。入力のいかなる内容もページから出ることはなく、ロードされた後はオフラインで動作する。