PX / REM Guide

pxとrem、どっちで書けばいいの?──「なんとなく」使い分けていた私(わたくし)が調べた記録

Web制作をしていて「font-size: 24px」と書くか「1.5rem」と書くか、迷ったことはありませんか? 以前の私(わたくし)は「なんとなくpxが分かりやすいから」とずっとpxばかり使っていました。しかし、「アクセシビリティ(誰にとっても読みやすいこと)」を意識し始めると、remの重要性に気づかされました。このページでは、その時に調べまくって整理した「文字サイズと余白の単位選びの基準」をまとめます。もう「なんとなく」での単位選びは卒業しましょう。

文字サイズ 余白スケール アクセシビリティ

作成者: かたかた / 更新日: 2026年9月22日

ざっくり言うと

動かしたくないものはpx、ユーザーに合わせて伸び縮みしてほしいものはrem。これが基本線です。

たとえばボーダー線の1pxやアイコンの微調整は、ユーザーがブラウザの文字サイズ設定を変えても「この太さで固定してほしい」。だからpx。本文の文字サイズや余白は、ブラウザの設定で文字を大きくしている人にも合わせて伸びてほしい。だからrem。

ちなみに「全部の単位をremにしろ」と言われることがありますが、それは極端です。使い分けが正解です。

よくある実務パターン

場面 おすすめ 理由
本文テキスト rem ユーザーの文字サイズ設定に追従しやすい
余白・マージン rem 文字が大きくなったときに全体のレイアウト比率を保ちやすい
1px / 2px の罫線 px 意図した太さをシャープに保ちやすい
小さなアイコンの微調整 px ズレが見えやすいので固定値が扱いやすい

1rem = 16px?10px?──ここが一番混乱するところ

rem は、ルート要素(通常は html)の font-size を基準にする相対単位です。多くのブラウザでは初期値が16px相当ですが、ユーザー設定やCSSでrootの文字サイズが変われば、1remの実寸も変わります。

rootが16px相当なら、24px = 1.5rem、32px = 2rem、14px = 0.875remです。ここで暗算がしんどくなる。

html { font-size: 62.5%; } として計算を簡単にする方法もあります。ただし、ブラウザ側の基準が16px相当なら1remが10px相当になるという話で、常に10pxへ固定されるわけではありません。ユーザーの文字サイズ設定を尊重したい場合は、rootの基準値を上書きしない設計も検討します。

ただし!複数人でコードを触る時はこのルールを共有してないと大カオスになります。「え、1remって16pxじゃないの?」って人が混ざるとレイアウトがすべてズレます。個人開発なら好きなほうでいい。チームなら先に決めてREADMEに書く。

私(わたくし)の結論: KatakataLabでは16px基準で統一して開発しています。他の人のコードやライブラリと混ぜたときに事故りにくいのが一番の理由です。

やりがちなミス

文字だけremにして余白はpxのまま

これが一番多い。ブラウザの文字サイズを大きくした人が見たとき、文字は大きくなるのに余白はそのままで窮屈になる。文字と余白は同じ単位で揃える。

「1rem = 10pxだよね?」を書かない

あとから入った人が16px前提で書いて全部ズレる、という事故が起きます。READMEかスタイルガイドに書いておくだけで防げるので、忘れずに。

KatakataLabの「px ⇔ rem 変換ツール」はここが便利!

「このデザインの14pxって何remだっけ?」「0.875remって何ピクセル?」と迷ったときに、秒速で変換できるのがKatakataLabの変換ツールです。

💡 主な特徴

  • 双方向のリアルタイム変換:pxを入力すればremが、remを入力すればpxが、入力に合わせてその場で計算されます。
  • 「16px基準」も「10px基準」も、基準入力の横のボタンで切り替え:プロジェクトの実際の root を入れて計算できます。
  • 文字サイズプレビュー機能:数値だけではなく、「このサイズで文字がどう見えるか」が画面上にサンプルテキストとして表示されるため、仕上がりの視覚的なイメージが湧きやすいです。

🙌 こんな人に特におすすめです!

「CSSコーディングをする際に、ピクセル数からremへの計算が面倒でついつい暗算や電卓で時間を取られているコーダー・開発者の方」に最適です。ブックマークに登録しておくだけで、日々のコーディング速度がぐっと上がりますよ!

サイズ段階を揃えるときの実務メモ

見出し・本文・注釈・ボタンをバラバラのpxで書いてしまうと、後から「ちょっと大きく」が地獄になります。次のように段階を先に決めると安定します。

役割16px基準の例remメモ
本文16px1rem基準そのもの
小さめ注釈14px0.875rem可読性の下限に注意
小見出し20px1.25rem本文との差をはっきり
見出し24px1.5remページ内で統一
大きい見出し32px2remヒーローなど限定利用

px / rem 変換で双方向に確認し、デザイン稿がpxでも実装がremでも、同じ段階表に戻せるようにします。

アクセシビリティとユーザー設定

ブラウザやOSで文字サイズを大きくしている人でも読めるかは、rem を使う理由のひとつです。ルートのフォントサイズが変わると rem は連動しますが、固定pxだらけのレイアウトははみ出しや重なりが起きやすくなります。

  • 本文に近い要素は rem で段階管理する。
  • 1pxの境界線など「見た目の線」は px のままでよいことが多い。
  • 完成後は、ブラウザの文字サイズを大きくして崩れないか一度見る。

よくある質問

Q. 全部remにすればいい?

A. それはやりすぎです。ボーダー線を0.0625remとか書いてもコードが読めなくなるだけなので、罫線やシャドウの微調整はpxのほうがいいです。

Q. 16px基準と10px基準、どっち?

A. チーム全員が同じ前提を持てることが最優先です。1人での開発や外部CSSと混ぜる場合も、まずrootの設定を確認します。特別な理由がなければ、ブラウザの一般的な初期値(16px相当)を前提にし、必要なら変換ツール側の基準値を合わせる方が前提を共有しやすいです。

Q. デザインがpx指定なのに実装はrem。どう付き合う?

A. まず基準(多くの場合16)を合意し、変換表で往復できるようにします。レビュー時は「この24pxは1.5remか」をツールで確認し、感覚のズレを減らします。

参考: MDN <length> — rem(remはrootのfont-sizeに対する相対値。16pxは一般的なブラウザ初期値で、ユーザー設定により変わり得ます。)

更新日: 2026年9月22日 / 作成者: かたかた

変換ミスで起きやすい事故

  • 基準が16なのに、別プロジェクトの10px前提の数値をそのまま貼る
  • 見出しだけrem、本文がpxで、ユーザーの文字サイズ変更時にバランスが崩れる
  • デザインの「見た目24px」と実装の「line-height込みの高さ」を混同する
  • 余白を全部remにすると、1pxのズレ調整が難しくなる

迷ったら変換ツールで往復し、実例集のpx/rem例と同じ入力で一度確認すると安心です。チームでは「基準は16」とREADMEに1行書いておくだけでも事故が減ります。

デザイン稿(px)からCSS(rem)へ渡す手順

Figma などの稿が px 指定でも、実装を rem にしたい場面はよくあります。KatakataLabでの実務手順は次のとおりです。

  1. 基準を決める(個人開発・外部CSS併用なら多くの場合 16px)。
  2. 稿の文字サイズ・余白のうち、段階管理したい値だけを表に書き出す。
  3. px / rem 変換で 16 基準にそろえて rem を出す。
  4. 見出し・本文・注釈・ボタンの4段階に丸めて、近い値は統一する。
  5. 実装後にブラウザの文字サイズを大きくし、はみ出しがないか見る。

「全部ぴったり変換」より「段階として一貫している」方が、後からの調整が楽です。1px差の影や境界線は、無理に rem にしない判断もアリです。

いつ px のまま残すか

対象おすすめ理由
本文・見出しrem文字サイズ設定の影響を受けやすい
大きな余白の段階rem か 段階トークンレイアウトの比率を保ちやすい
1px の線・影px端数の rem が読みにくい
アイコンの見た目サイズ場合によるフォント連動なら rem、固定絵なら px も可

「全部 rem」はルールとしては綺麗でも、コードの読みやすさと現場の速度を落とすことがあります。目的は単位の統一ではなく、読みやすさと保守のしやすさです。

このガイドの限界

ブラウザやOSの文字サイズ、ズーム、ユーザーCSSは環境差があります。変換ツールは入力値から rem/px を求めるだけで、完成画面の見栄えまでは保証しません。公開前の最終確認は、実際の端末幅と文字サイズ設定で行ってください。