CSS 단위 변환기

CSS 단위 핵심 공식 참조표

px → rem 조견표 (root 16px)

아래 표는 root font-size 16px 기준의 px ÷ 16 산술입니다. 한 가지 주의 — 16px은 CSS 표준이 정한 수치가 아닙니다. W3C 명세(CSS Values Level 4)는 rem을 “루트 요소 font-size와 같다”로만 정의하고 숫자를 정하지 않으며, MDN도 “일반적인 브라우저 기본값(common browser default)이 16px이지만 사용자 설정으로 바뀔 수 있다”고 서술합니다. rem을 쓰는 이유가 정확히 이 지점입니다 — 사용자가 브라우저 설정에서 기본 글꼴을 20px로 키우면 px로 고정한 텍스트는 그대로지만, rem으로 쓴 텍스트는 20 ÷ 16 = 1.25배로 함께 커져 사용자의 선택을 존중합니다.

13px = 0.8125rem처럼 암산이 지저분한 값도 표 그대로 쓰면 되고, 위 변환기에서 root 값을 바꾸면 즉시 재계산됩니다.

rem vs em 완전 비교

px→rem 62.5% 트릭(1rem = 10px)의 함정

html에 font-size: 62.5%를 선언하면 브라우저 기본 16px × 0.625 = 10px가 되어 1.6rem = 16px, 2.4rem = 24px처럼 암산이 쉬워집니다. 문제는 rem이 문서 전체에 적용되는 전역 기준이라는 점입니다. Shadow DOM 내부의 rem까지 예외 없이 바뀌므로, 1rem = 16px를 전제로 만들어진 서드파티 코드가 전부 62.5% 크기로 줄어듭니다.

타이포그래피·여백 기본값을 rem으로 정의한 Bootstrap 5, spacing 1단위 = 0.25rem인 Tailwind CSS, rem을 쓰는 임베드 위젯(댓글·결제창 등)이 대표적인 충돌 지점입니다. 게다가 이 트릭은 프로젝트 전체를 한 번에 바꾸는 일괄 전환만 가능해, 이미 rem이 섞인 코드베이스에 점진적으로 도입할 수 없습니다. 62.5%가 고정 font-size: 10px 선언보다 나은 점은 사용자의 브라우저 글꼴 크기 설정에 비례해 확대된다는 것 하나인데, 루트를 100%로 두어도 같은 이점을 얻습니다. 결론적으로 외부 CSS를 전부 통제할 수 없다면 루트를 100%(16px)로 유지하고 px ÷ 16 나눗셈은 변환기에 맡기는 편이 안전합니다 — 이 변환기의 root font-size 기본값이 16인 이유입니다.

Tailwind와 rem — spacing scale·임의값

Tailwind의 spacing 유틸리티는 rem 기반입니다. v3 공식 문서의 명문은 “spacing 1단위 = 0.25rem, 일반적인 브라우저 기본값에서 4px” — v4는 같은 결과를 테마 변수 --spacing: 0.25rem에 숫자를 곱하는 방식으로 만듭니다(2026-07 v3·v4 문서 기준). 단위가 rem이므로 위에서 본 ‘사용자 글꼴 설정 존중’이 유틸리티 전체에 자동으로 적용됩니다.

스케일에 없는 값은 대괄호 임의값(arbitrary value) 문법으로 즉석 생성합니다. 공식 문서 예시는 top-[117px]·text-[22px]이고, w-[13px]처럼 어느 유틸리티에나 같은 문법이 통하며 lg:top-[344px]처럼 반응형·상태 수정자와도 결합됩니다. 다만 공식 문서가 임의값을 소개하는 맥락 자체가 “배경 이미지를 딱 맞는 자리에 놓기 위해 top: 117px이 정말로 필요할 때” — 즉 1회용 탈출구입니다. 같은 값이 여러 곳에서 반복된다면 임의값을 복붙하기보다 테마 변수로 등록해 일반 유틸리티처럼 쓰는 편이 유지보수에 낫습니다.

clamp() 완전 가이드

clamp(최솟값, 선호값, 최댓값)은 뷰포트 크기에 따라 값을 부드럽게 변화시키면서도 안전한 상·하한을 보장합니다.

타이포 스케일 실전 — h1~캡션 clamp() 세트

위 선형 보간 공식을 실제 타이포 단계에 적용한 세트입니다. 뷰포트 기준은 360~1440px — 이 페이지 clamp() 생성기의 기본값과 같아서, 같은 px를 입력하면 아래와 동일한 코드가 나옵니다. MDN 정의대로 clamp(MIN, VAL, MAX)는 max(MIN, min(VAL, MAX))로 해석되므로, 선호값(가운데 vw 식)이 어떤 값이 되어도 결과는 항상 MIN~MAX 사이로 잘립니다. 이 등가식을 그대로 계산해 보면, 실수로 MIN을 MAX보다 크게 지정했을 때 바깥쪽 max()가 마지막에 적용되어 MIN이 이긴다는 것도 도출됩니다.

단계가 내려갈수록 vw 계수(기울기)가 작아지는 점에 주목하세요 — 본문·캡션은 360→1440px 전 구간에서 각각 2px·1px만 변합니다. 변화 폭이 이 정도로 작은 단계는 clamp() 없이 고정 rem으로 두는 선택도 실용적입니다. 큰 제목일수록 유동의 이득이 크고, 작은 글자일수록 고정이 단순합니다.

100vh 모바일 주소창 문제 — dvh·svh·lvh

모바일 브라우저의 주소창은 스크롤에 따라 나타났다 사라지지만, 기존 100vh는 주소창이 접힌 가장 큰 화면 기준으로 계산되는 경우가 대부분입니다. 그래서 첫 화면에서 100vh 요소의 하단 — 고정 버튼·CTA — 이 주소창에 가려지는 문제가 생깁니다. CSS Values Level 4는 이를 해결하는 세 가지 뷰포트 높이 단위를 추가했습니다.

기존 vh를 dvh로 바꿔야 하는 경우는 스크롤 중에도 요소가 항상 보이는 영역과 일치해야 할 때뿐입니다. dvh는 주소창이 움직일 때마다 다시 계산되므로 대형 레이아웃이나 font-size에 쓰면 스크롤 중 요소가 계속 늘었다 줄었다 합니다. 첫 화면 잘림만 문제라면 svh가 더 안정적입니다. px→vh 공식(px ÷ viewportHeight × 100)은 세 단위에 그대로 적용되며 기준 높이만 달라집니다.

aspect-ratio vs padding-top trick

line-height unitless 권장 이유

unitless(단위 없는) line-height는 자식 요소에 상속될 때 자식의 font-size로 재계산됩니다. 반면 em·%는 계산된 px값이 그대로 상속되어 의도와 달라질 수 있습니다.

Figma → CSS 변환 치트시트

자주 묻는 질문 (FAQ)

함께 쓰면 좋은 도구