DP to PX & PX to DP Converter for Android

<!-- res/values/dimens.xml -->
<dimen name="spacing">16dp</dimen>

// Compose
16.dp

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

What is dp, and why does Android use it?

dp (density-independent pixels, sometimes written dip) is Android’s unit for UI layout. Unlike a raw pixel, 1dp is defined relative to a 160 dpi reference screen, so the same dp value produces the same physical size across phones with wildly different pixel densities. A 48dp touch target looks and feels the same whether it renders as 48 real pixels on an old mdpi device or 144 real pixels on a modern xxxhdpi flagship. px, by contrast, is an absolute unit — a raw device pixel with no awareness of screen density at all.

That’s why Android layouts are authored in dp, but you still need to convert to px for asset exports, QA screenshots, matching a pixel measurement from a device, or debugging why something looks a different size than expected.

The dp to px formula (and the reverse)

Both directions come down to one relationship and the screen’s density — the same equation Android’s own pixel-density guide documents:

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

160 is mdpi, Android’s 1× baseline. At 320 dpi (xhdpi), the ratio is 320 / 160 = 2, so 16dp becomes 32px. At 480 dpi (xxhdpi), the ratio is 3, so the same 16dp becomes 48px. The converter above does this instantly in both directions — pick a density bucket, type into either field, and read the result.

dp vs px — the practical difference

The two units answer different questions. px asks how many hardware pixels?; dp asks how big should this look in the user’s hand? Everything else follows from that:

	dp	px
What it measures	Physical size (1dp = 1/160 inch)	One hardware pixel
Scales with density	Yes — automatically	No
Same physical size on every device	Yes	No
Where you use it	Layouts, margins, icons, touch targets	Canvas drawing, bitmap sizes, raw metrics
16dp on xxhdpi	Renders as 48px	16px stays 16 pixels — about a third the size

The last row is the whole argument. A 16px margin authored on a modern xxhdpi phone looks reasonable on that device and then collapses to a hairline on a lower-density screen — or the reverse. The same 16dp margin is the same physical width everywhere. Author every layout dimension in dp, and convert to px only when an API forces you to — Canvas operations, Bitmap dimensions, and anything reading DisplayMetrics directly all speak raw pixels.

Common dp to px values at every density

These are the dp values you’ll reach for most, converted against every standard bucket. Multipliers are 1× (mdpi), 1.5× (hdpi), 2× (xhdpi), 3× (xxhdpi), and 4× (xxxhdpi):

dp	mdpi	hdpi	xhdpi	xxhdpi	xxxhdpi	Reference
4dp	4	6	8	12	16
8dp	8	12	16	24	32	grid unit
12dp	12	18	24	36	48
16dp	16	24	32	48	64	default margin
24dp	24	36	48	72	96	standard icon
32dp	32	48	64	96	128
48dp	48	72	96	144	192	min touch target
56dp	56	84	112	168	224	FAB / toolbar
64dp	64	96	128	192	256
108dp	108	162	216	324	432	adaptive icon layer

All values in px. The pattern is just px = dp × multiplier, so anything not listed is a quick multiply — or type it into the converter above, which shows the same breakdown across every bucket at once for whatever value you enter.

Android density buckets

Android groups real-world screen densities into named buckets so a handful of asset sizes can cover almost every device:

Bucket	dpi	Multiplier
ldpi	120	0.75×
mdpi	160	1× (baseline)
tvdpi	213	1.33× (legacy, some TVs and older tablets)
hdpi	240	1.5×
xhdpi	320	2×
xxhdpi	480	3×
xxxhdpi	640	4×

tvdpi is a legacy bucket you’ll rarely target directly today, but it still shows up on some older tablets and set-top boxes, so it’s included for completeness.

Why dp has a fixed physical size

1dp is defined as exactly 1/160 of an inch, so its physical size never changes — only the pixel count needed to draw it does. A 12dp icon measures roughly 1.9mm across whether it renders as 12 real pixels on mdpi or 48 real pixels on xxxhdpi. That consistency is the entire reason dp exists: it lets one layout value look the same size in your hand on every device, regardless of how many physical pixels the screen packs in.

This is also why Android’s accessibility guidance sets the minimum touch target at 48dp — at 48dp a button is roughly 7.6mm, about a fingertip, on every device. The converter above shows this alongside every result so you can sanity-check whether a value is sensible, not just what it converts to.

Why you shouldn’t use mm, in, or pt in Android layouts

Android does support physical units (mm, in, pt), but they resolve against DisplayMetrics.xdpi — the screen’s physical pixels-per-inch — not density, the bucket-derived value every dp conversion uses. These are different numbers on nearly every real device: a phone’s marketing spec might say 428 ppi while Android reports a densityDpi of 420. Worse, xdpi is frequently misreported by OEM firmware. So even though mm/in/pt are valid resource units, using them for layout ties your UI to a measurement that’s both different from dp and less reliable — which is why they see almost no real-world use outside print-style output.

That mismatch is the root cause of the classic “why is my dp wrong on this device” bug report. Stick to dp for layout — it’s the only unit guaranteed to use the density value Android actually renders with. One related trap: launcher icons belong in mipmap-* folders, not drawable-* — launchers are allowed to render icons up to 25% larger than the device’s bucket, and density-based APK splits strip drawable-* folders but keep every mipmap-* density.

Custom and in-between DPI devices

Not every device matches a named bucket exactly. Many recent phones report densities like 400, 420, 440, or 560 dpi — values that sit between the standard buckets. Rounding one of these to the nearest bucket introduces error, so use the Custom option above and enter the device’s exact DPI (visible in DisplayMetrics.densityDpi, or Android Studio’s Device Manager) for an accurate conversion instead of an approximation.

dp to px in Kotlin, Java & Android Studio

When you’re converting on-device rather than by hand, never hardcode a multiplier — read the live density so your code stays correct on in-between-bucket screens. The canonical API is TypedValue.applyDimension:

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

// Kotlin — extension functions for both directions
fun Float.dpToPx(context: Context): Float =
    this * context.resources.displayMetrics.density

fun Float.pxToDp(context: Context): Float =
    this / context.resources.displayMetrics.density

// Java — dp → px and back
float px = TypedValue.applyDimension(
    TypedValue.COMPLEX_UNIT_DIP, 16f, getResources().getDisplayMetrics());

float dp = px / getResources().getDisplayMetrics().density;

displayMetrics.density is simply densityDpi / 160, so multiplying by it is the same formula the converter above uses. Most of the time you shouldn’t need any of this in Android Studio: put the value in res/values/dimens.xml as <dimen name="spacing">16dp</dimen> and the framework converts it for you at inflation time. Reach for the programmatic version only when a value is computed at runtime.

dp to px in Jetpack Compose

Compose treats density as a composition local rather than something you pull off Resources, so conversions happen inside a with(LocalDensity.current) block:

// Compose — dp → px
val px = with(LocalDensity.current) { 16.dp.toPx() }

// Compose — px → dp
val dp = with(LocalDensity.current) { 48f.toDp() }

The important thing is that you rarely need this in Compose at all. Modifiers already accept Dp values directly — Modifier.padding(16.dp) and Modifier.size(48.dp) handle the conversion internally. You only drop down to raw pixels when you’re inside Canvas, writing a custom layout, or calling a graphics API that takes floats, since those work in the pixel coordinate space — as the Compose graphics docs put it, every drawing operation is performed in pixel sizing.

Dp is also a first-class type with arithmetic, so 16.dp * 2 and 8.dp + 4.dp both work — there’s no reason to convert to a plain number just to do math on a dimension.

How Android rounds dp to device pixels

The framework doesn’t truncate — it rounds. Internally it computes (int)(dp * density + 0.5f), which rounds to the nearest whole pixel. 10dp at a 2.75× density (440 dpi) is mathematically 27.5px, but the device actually draws 28px. This converter shows the exact fractional value alongside the Android-rounded pixel so you always know which number a real device will render.

Figma px to dp for Android handoff

Figma has no dp unit — it works in px — but the handoff is simpler than it looks, because a 1× Figma frame maps one-to-one onto dp. Both are built on the same 160 dpi reference, so a 24px icon in the mockup is 24dp in your layout, and a 16px gap is 16dp of padding. No conversion needed.

The conversion only enters when you export raster assets, where each density bucket needs its own scaled PNG. Figma’s export multipliers line up exactly with Android’s buckets:

• 1× → drawable-mdpi
• 1.5× → drawable-hdpi
• 2× → drawable-xhdpi
• 3× → drawable-xxhdpi
• 4× → drawable-xxxhdpi

Two things go wrong in practice. First, designing at 2× or 3× and forgetting to divide — if the frame is a 2× artboard, every number a designer quotes is double the dp value, so a “48px” icon is really 24dp. Second, off-grid values: a 13px spacing decision produces 13dp, which lands on awkward fractional pixels at 1.5× (19.5px) and gets rounded by the framework. Sticking to the 4dp and 8dp grid keeps every bucket landing on whole pixels. Paste any px value into the converter above to check what a given bucket will actually render.

Android dpi vs print DPI

These are different measurements that share an abbreviation, and conflating them causes real confusion. Print DPI (dots per inch) describes how finely a printer lays ink on paper — it’s a property of the output device and only becomes a physical size when paired with a pixel count. A 3000px image at 300 DPI prints at 3000 ÷ 300 = 10 inches; the same file at 150 DPI prints at 20 inches. The pixels never changed, only the density you chose to print them at.

Android’s densityDpi is a different animal. It isn’t measured off the physical panel at all — it’s a bucket value the system reports (160, 240, 320, 480…) that tells the framework which drawable folder to load and what to multiply your dp values by. A phone whose true panel density is 428 ppi will typically report a densityDpi of 420, because it’s snapped to a usable bucket rather than measured precisely.

So a question like “how many pixels are in 1 DPI?” has no answer: DPI is a rate, not a count. Pixels only appear once you supply a length — pixels = DPI × inches. For Android work you can ignore print DPI entirely; the only density that matters is the one in DisplayMetrics.

When you actually need this conversion

• QA and bug reports. A tester reports a 2px gap on a specific device; you need to know what that is in dp to find the layout value that’s wrong.
• Asset exports. Exporting an icon or image at a specific density bucket means knowing the exact pixel dimensions your dp size maps to.
• Cross-platform and design handoff. A designer working in px (Figma, Sketch) hands off specs that need converting to dp for the Android layout — and the reverse, when verifying a build against a pixel-based mockup.
• Legacy code and tvdpi devices. Older codebases sometimes hardcode pixel values; converting them to dp makes the layout density-independent going forward.

Related tools

Shipping the icons as well as the layout? The App Icon Generator produces the full native size set for Android, iOS and more from a single source image — including the 108dp adaptive icon layers this page keeps referencing. Building a web front end alongside the app? The CSS px to rem converter solves the identical scaling problem for responsive typography and spacing. And since Material’s 48dp touch target is only half of an accessible control, check your colors against WCAG with the color contrast checker. Building for iOS too? The iOS points to pixels converter handles the same @1x/@2x/@3x scaling problem for Apple’s platform.

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