Introduction

On Android, raw pixels are not a reliable unit for defining UI size because devices have different screen densities. A view that is 100 pixels wide on one device can look physically much smaller on another. That is why Android uses dp, short for density-independent pixels, as the standard layout unit.

What dp Represents

dp is a virtual unit that scales with screen density. The baseline density is 160 dots per inch. At that density, 1 dp maps to 1 px. At higher densities, more pixels are used to represent the same physical size.

In practice, Android gives you a density scale factor. The simplest conversion formula is:

• 'dp = px / density'
• 'px = dp * density'

Here, density is typically something like 1.0, 1.5, 2.0, 3.0, or 4.0 depending on the device class.

Converting Pixels to dp in Code

The recommended way is to use DisplayMetrics from the current context.

1import android.content.Context
2import kotlin.math.roundToInt
3
4fun pxToDp(context: Context, px: Int): Int {
5    val density = context.resources.displayMetrics.density
6    return (px / density).roundToInt()
7}

Usage:

val dp = pxToDp(this, 48)
println(dp)

This returns an integer value suitable for many UI calculations.

Converting dp Back to Pixels

Many UI APIs ultimately need pixel values at runtime. For example, when setting padding or drawing dimensions programmatically, convert from dp to px.

1fun dpToPx(context: Context, dp: Int): Int {
2    val density = context.resources.displayMetrics.density
3    return (dp * density).roundToInt()
4}

This is the direction you will probably use more often in application code, because layouts are usually designed in dp and converted to pixels only when needed by a low-level API.

Why Layout XML Should Usually Stay in dp

If you are defining margins, widths, heights, or padding in XML, use dp directly instead of converting manually.

1<TextView
2    android:layout_width="120dp"
3    android:layout_height="wrap_content"
4    android:padding="16dp"
5    android:text="Hello" />

This lets Android handle density scaling automatically. Manual conversion is mainly for runtime code paths.

A Concrete Example

Suppose a device has a density of 2.0, meaning it uses twice as many pixels as the baseline for the same physical size.

• '48 px becomes 24 dp'
• '24 dp becomes 48 px'

That explains why copying pixel values from design tools directly into Android code often leads to inconsistent sizing. Without density-aware conversion, the UI becomes device-dependent.

dp Versus sp

A frequent source of confusion is mixing dp and sp.

• use dp for layout size and spacing
• use sp for text size

sp behaves like dp but also respects the user's font scaling preference. If you use dp for text, accessibility suffers.

Utility Extensions for Cleaner Code

In Kotlin projects, extension properties can make these conversions less repetitive.

1import android.content.res.Resources
2import kotlin.math.roundToInt
3
4val Int.dpToPx: Int
5    get() = (this * Resources.getSystem().displayMetrics.density).roundToInt()

Then you can write:

val paddingPx = 16.dpToPx

This is convenient, but use application or view resources when possible if you need the exact current configuration rather than the system default.

Common Pitfalls

The biggest mistake is designing in pixels and carrying those pixel measurements directly into Android layouts. That makes the UI inconsistent across densities.

Another issue is doing integer division too early. If you divide pixel values before converting to floating point, you can lose precision.

Do not use dp for text size. Use sp.

Also be careful with Resources.getSystem() in libraries or themed contexts. It can be fine for utilities, but if you already have a Context, using that context's display metrics is usually clearer and safer.

Summary

• Android uses dp so layouts stay physically consistent across screen densities.
• Convert pixels to dp with px / density.
• Convert dp to pixels with dp * density.
• Use dp in XML layouts whenever possible instead of converting manually.
• Use sp for text, not dp.
• Prefer context-aware display metrics when converting values in runtime code.