SP to PX & PX to SP Converter for Android

<!-- res/values/dimens.xml -->
<dimen name="text_size">16sp</dimen>

// Compose
fontSize = 16.sp

// Views
TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_SP, 16f, resources.displayMetrics)

What is sp, and why does Android need a separate unit for text?

sp (scale-independent pixels) is Android’s unit for text size. It starts from exactly the same density scaling as dp — 1sp renders larger on a denser screen, in the same proportions, so text looks the same physical size across devices. Where it differs is the second input: sp also multiplies by the user’s system font-scale preference, set under Settings > Display > Font size. Someone who finds default text too small can raise that setting once, system-wide, and every app that correctly used sp for text respects it immediately — no extra code required on your end.

That’s the entire reason the unit exists. If Android only had dp, there would be no way for a user to make text bigger without also inflating every margin, icon, and touch target in every app they use.

The sp to px formula (and the reverse)

Both directions extend the dp formula with one extra factor, the font scale:

• sp → px: px = sp × (dpi / 160) × fontScale
• px → sp: sp = px ÷ (dpi / 160) ÷ fontScale

dpi / 160 is the same density ratio the dp to px converter uses. fontScale defaults to 1.0 and is read live from Configuration.fontScale — it’s never something you set in code. At mdpi (160 dpi) with the default scale, 1sp = 1px, same as dp. At xxhdpi (480 dpi, a 3× density) with a 130% font scale, 16sp × 3 × 1.3 = 62.4px, which Android rounds to 62px. The converter above does both multiplications instantly — pick a density and font scale, type into either field, and read the result.

sp vs dp — choosing the right unit for text

Both units scale identically with screen density. The only difference is the font-scale factor, but that difference has a hard rule attached to it:

	sp	dp
Scales with screen density	Yes	Yes
Scales with user font-size setting	Yes	No
Use for	Every fontSize value	Margins, padding, icons, touch targets
16 at xxhdpi, 130% font scale	≈ 62px	48px (unaffected by font scale)

Get this backwards and you break accessibility in one of two directions. Text sized in dp ignores the user’s font-size preference entirely — someone who deliberately increased system text size for readability gets no benefit inside your app, which is exactly the failure sp was built to prevent. The opposite mistake — sizing layout dimensions in sp — makes padding, icon boxes, and touch targets balloon every time text grows, often producing cramped or overflowing screens instead of just bigger, more readable text. Text goes in sp. Everything around the text goes in dp.

What is fontScale, and where do users change it?

fontScale is a system-wide multiplier, exposed as Configuration.fontScale and, in Compose, as LocalDensity.current.fontScale. Users set it under Settings > Display > Font size (exact wording varies slightly by OEM). The typical steps are:

Preset	Scale
Small	0.85×
Default	1.0×
Large	1.15×
Larger	1.30×
Extra large	1.50×
Largest (accessibility)	2.00×

Android 12 and later split out a separate “Larger accessibility sizes” toggle that unlocks the top end of that range (up to 200%) independently of the regular font-size slider. Whatever the user picks, it applies to your entire app the moment they change it — your code should never hardcode or cache a font scale value.

Live preview: your sp value across every font scale

Type a value into the sp field above and the preview row renders it as real text at four font scales — 0.85×, 1.0×, 1.3×, and 2.0× — side by side, each labeled with its computed pixel size. This is the fastest way to sanity-check a design decision: a caption that looks fine at 100% may become uncomfortably cramped against its container at 200%, and the only way to know is to look at it rendered, not just at the number.

Common sp values across densities

The sp sizes you’ll use most, at the default 100% font scale:

sp	mdpi	hdpi	xhdpi	xxhdpi	xxxhdpi	Typical use
11sp	11	16.5	22	33	44	Label Small (M3)
12sp	12	18	24	36	48	Caption / Body Small
14sp	14	21	28	42	56	Body Medium / Label Large
16sp	16	24	32	48	64	Body Large / default body text
18sp	18	27	36	54	72	Subtitle
20sp	20	30	40	60	80	Section header
24sp	24	36	48	72	96	Headline Small

Every value scales again once the font scale leaves 100% — the all-densities table above applies your chosen font scale to any sp value you enter, at every bucket simultaneously.

Material 3 type scale

Material 3 defines fifteen named text roles, from Display Large at 57sp down to Label Small at 11sp, each with its own recommended letter-spacing — the values below match Google’s own type-scale tokens reference:

Role	sp	Tracking
Display Large	57	-0.25
Display Medium	45	0
Display Small	36	0
Headline Large	32	0
Headline Medium	28	0
Headline Small	24	0
Title Large	22	0
Title Medium	16	0.15
Title Small	14	0.1
Body Large	16	0.5
Body Medium	14	0.25
Body Small	12	0.4
Label Large	14	0.1
Label Medium	12	0.5
Label Small	11	0.5

The type-scale table above converts every role at your chosen density and font scale, so you can see exactly how many pixels a Body Large string renders as on a 480 dpi screen at 150% font scale — not just what it looks like on the design spec.

Designing for 200% font scale

The largest accessibility setting, 200%, is where layouts most often break, and it’s worth testing deliberately rather than eyeballing 100% and hoping — exactly what Android’s own guide on supporting user-scalable content recommends. A few concrete rules that hold up:

• Never fix the height of a container that wraps text. Let it grow with wrap_content / Compose’s default sizing, or the text will clip.
• Reserve maxLines + ellipsis only where truncation is genuinely acceptable — a list-item subtitle, not a button label a user needs to read in full.
• Keep icons and touch targets in dp, never sp. If they scaled with text, a 200% font setting would also balloon every icon, compounding the space problem instead of just making text legible.
• Check line-height, not just font-size. A tight lineHeight that looked fine at 16sp can cause overlapping lines once the same text renders at 32sp-equivalent size.

sp to px in Kotlin & Java

The canonical on-device conversion, using the same TypedValue API dp uses, just with a different unit constant:

// Kotlin — the canonical sp → px conversion
val px = TypedValue.applyDimension(
    TypedValue.COMPLEX_UNIT_SP, 16f, resources.displayMetrics
)

// Java — sp → px
float px = TypedValue.applyDimension(
    TypedValue.COMPLEX_UNIT_SP, 16f, getResources().getDisplayMetrics());

TypedValue.COMPLEX_UNIT_SP already factors in both density and scaledDensity — you don’t need to multiply by fontScale yourself if you use this API. Most of the time you won’t touch this at all: put the value in res/values/dimens.xml as <dimen name="text_size">16sp</dimen> and set it via android:textSize, and the framework converts it for you at inflation time.

sp to px in Jetpack Compose

Compose reads both density and font scale from the same composition local:

// Compose — sp → px (already includes fontScale)
val px = with(LocalDensity.current) { 16.sp.toPx() }

This is one place Compose text differs from Compose dp: Dp.toPx() ignores font scale entirely, while TextUnit.toPx() (used for .sp values) multiplies by LocalDensity.current.fontScale automatically, because text is the one thing meant to respond to it. As with dp, you rarely need this directly — Text(fontSize = 16.sp) and TextStyle(fontSize = 16.sp) already handle the conversion internally. Reach for raw pixels only inside Canvas, a custom Layout, or a graphics API that requires floats.

Figma letter spacing to Android

Figma expresses letter spacing (tracking) as a percentage of the font size, not an absolute unit — which is exactly why the panel above reuses the sp value you’ve already entered instead of asking for a separate font size. The conversion is:

em = figma_percent / 100
sp_tracking = em × font_size_sp

A 2% tracking spec on 16sp text is 0.02 × 16 = 0.32sp. But neither Android XML nor Compose take that sp value directly for letter spacing — both actually want the em figure:

<!-- res/values/styles.xml — letterSpacing is unitless em, not sp -->
<item name="android:letterSpacing">0.02</item>

// Compose — matches a Figma percentage exactly
letterSpacing = 0.02.em

The reason it’s em and not sp: tracking needs to compound with whatever size the text renders at, the same way em works in CSS. A fixed sp offset would look proportionally tight on a large headline and proportionally loose on a small caption — the opposite of what a percentage-based design spec intends. Compose’s TextUnit supports both .sp (absolute, rarely what you want for tracking) and .em (relative, matches Figma) — for any handoff coming from a percentage-based tool, reach for .em.

When you actually need this conversion

• Accessibility QA. Confirming your text actually grows at 130% and 200% font-scale settings, and that nothing clips or overlaps when it does.
• Design handoff. A Figma spec in px needs converting to sp for implementation, and a QA report measuring pixels on a screenshot needs converting back to the sp value that produced it.
• Cross-checking Material 3 roles. Verifying that a Body Large string actually renders at the pixel size the spec implies on a specific density and font-scale combination.
• Letter-spacing handoff. Turning a Figma tracking percentage into the em value Android’s letterSpacing attribute and Compose’s TextStyle both expect.

Related tools

Shipping the launcher icons for the same app? The App Icon Generator produces the full native size set for Android, iOS and more from one source image. And since accessible type needs accessible color too, check your palette against WCAG with the color contrast checker. Building the iOS side of a cross-platform app? The iOS points to pixels converter covers the equivalent @1x/@2x/@3x scaling for Apple’s platform.

Everything runs 100% client-side — nothing you type ever leaves your device.