PX → REM 转换器,免费
在像素与 rem 之间互相转换,可配置基础字号。
参考表
| PX | REM |
|---|
工作原理
REM 意为「root em」,相对于根元素的字号。浏览器默认使用 16 px。公式很简单:rem = px ÷ base,px = rem × base。如果您的项目使用不同的根值,请在上方修改基础字号。
常见问题
为什么使用 rem 而不是 px?
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重要:无障碍性因素
浏览器向用户暴露两种不同的缩放机制,它们对单位的处理方式各不相同:
- 浏览器缩放(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中实现可缩放排版的唯一方法是em,它是相对于父元素的font-size,而非根元素。经典问题:嵌套的带有基于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× */
三层嵌套列表会膨胀至接近两倍的正文大小,这几乎从未是预期效果。rem通过每次都锚定到根元素来解决这个问题,三层嵌套元素在1.2rem下全都是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」的笨拙运算。
无障碍性批评(当时提出,在后来的写作中得到强化):将根字体大小设置为62.5%,实际上缩小了用户在浏览器偏好中选择的任何值。因低视力而将默认字体大小设置为24px的用户会看到15px的正文文本,完全违背了使用rem的初衷。现代反驳意见是将根字体大小设置为62.5%,但明确将正文font-size声明为1.6rem(回到16px),这样用户覆盖设置仍能正确级联。许多团队完全跳过这个技巧,接受略显不那么优雅的数学运算。
何时使用rem,何时使用px:Comeau的框架
Josh W. Comeau的文章「px还是rem?」(2022年5月,2025年5月更新)为这一决策提供了最实用的单问题启发法。问:「这个值是否应该随用户增大浏览器默认字体大小而放大?」如果是,使用rem。如果否,使用px。
按照该测试:
- 使用rem的场合:font-size、垂直外边距/内边距(与排版节奏相关)、按钮宽度和其他内容形状的容器、行长最大宽度、断点(使布局在低视力用户放大后的合适尺寸处发生偏移)。
- 使用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刻意将<html>根元素保持在浏览器默认的16px(他们明确不使用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。请注意,覆盖根字体大小对自定义浏览器默认值的用户有无障碍性影响,请参阅上文62.5%技巧的讨论。
为何0.625rem不能精确渲染为10px?
在默认16px根字体大小下,数学上确实可以:0.625 × 16 = 10。但浏览器以亚像素精度渲染,并可能将最终值四舍五入到整数设备像素,因此0.625rem边框有时可能与硬编码的10px边框看起来略有不同,具体取决于显示器DPR。对于像素完美的1像素细线,直接使用1px;对于其他所有情况,基于rem的值是完全可以的。
可以在同一个样式表中混用rem和px吗?
可以,而且应该这样做。对应该随用户字体大小偏好缩放的内容使用rem(排版、垂直节奏、断点),对不应缩放的内容使用px(边框、图标细节、装饰性阴影)。Comeau的「这个值是否应该缩放?」问题是实用的过滤器;几乎每次答案都能直接映射到其中一个单位。
构建工具会自动将px转换为rem吗?
可以,像postcss-pxtorem和postcss-rem-to-responsive-pixel这样的PostCSS插件可以在构建步骤中将已编写CSS中的px值重写为rem,支持可配置的阈值(例如,「转换所有≥12px的内容」)。它们在迁移现有的以px为主的代码库时非常有用。像本页面这样的实时转换器对于一次性转换、设计规范查找以及手动学习数学运算仍然有用。
有任何内容会发送到服务器吗?
不会。转换就是一次除法,是在浏览器中本地运行的纯JavaScript算术。您输入的任何内容都不会离开页面;工具加载后可离线工作。