A px to rem converter workflow starts by treating the value as a design token, not a fixed physical size: divide Android pixels by the target density scale to get dp, divide iOS pixels by the @1x, @2x or @3x scale to get pt, and divide web pixels by the root font size to get rem. At the common 16px root size, 16px equals 1rem. Keep the canonical token in dp or pt, calculate exports from that token, and choose pixel dimensions that land on whole device pixels at each required scale.
Key takeaways
- •Android defines 1dp as 1px on a 160dpi mdpi display.
- •Android density buckets are mdpi 160, hdpi 240, xhdpi 320, xxhdpi 480 and xxxhdpi 640 dpi.
- •On iOS, 1pt maps to 1px at @1x, 2px at @2x and 3px at @3x.
- •With a 16px root font size, 1rem equals 16px.
- •A 0.5-device-pixel edge is anti-aliased, which can make a 1px rule look blurred.
This guide is for mobile UI/UX designers, founders and engineers who already work with iOS points, Android density independent pixels and CSS length units.
Time: 20 minutes · You'll need: A screen specification with the source value in px, An iOS target scale: @1x, @2x or @3x, An Android target density bucket or density scale, A browser or design-system root font-size setting, A calculator or token sheet
What's on this page
- •Choose one canonical spacing token
- •Calculate Android values with a px to dp converter
- •Convert px to pt for iOS layouts
- •Convert web pixels to rem without assumptions
- •Validate integer pixels at every export scale
- •Reference table
Convert px to dp, pt and rem step by step
1. Choose one canonical spacing token
Start with one semantic value, such as space-16, rather than four independently edited measurements. For cross-platform product work, record the intended logical value first: for example, space-16 = 16dp for Android and 16pt for iOS. This is a useful pairing because Android’s baseline is 160dpi and iOS points are logical layout units, not export pixels.
Do not make 16px the canonical mobile token unless the source is explicitly a web CSS specification. Pixels change meaning with Android density and iOS scale. A 16px raster measurement taken from an iPhone @3x screenshot represents 5.333pt, not 16pt. Write the source context beside every imported value: 16 CSS px, 16 @2x px, or 16 xhdpi px.
The result should be a token row with one owner and calculated platform outputs. This prevents a designer changing 8pt while an engineer retains an unrelated 8dp or 8px constant.
Tip: Use token names such as
space-8andspace-16; do not encode a density bucket such asspace-24-xhdpiinto the token name.
2. Calculate Android values with a px to dp converter
For a manual px to dp converter calculation, use dp = px ÷ density scale. Android defines 1dp as 1px at the mdpi baseline of 160dpi. The density scale is the bucket DPI divided by 160: mdpi is 1, hdpi is 1.5, xhdpi is 2, xxhdpi is 3, and xxxhdpi is 4.
For example, a 48px asset measured at xhdpi becomes 48 ÷ 2 = 24dp. The same 24dp layout target rasterizes to 24px at mdpi, 36px at hdpi, 48px at xhdpi, 72px at xxhdpi and 96px at xxxhdpi. Android uses the actual device density configuration to scale density independent pixels; density buckets are resource and targeting conventions, not permission to hard-code one screenshot’s pixels.
Use sp rather than dp for text sizes. Android scales sp according to the user’s font-size preference, so a 16sp label must not be converted into a fixed 16dp text size.
Tip: If a value originates in an Android screenshot, identify its density before dividing; a 24px measurement is 12dp at xhdpi but 8dp at xxhdpi.
3. Convert px to pt for iOS layouts
For px to pt mobile conversion, use pt = px ÷ scale. On iOS, 1pt is 1px at @1x, 2px at @2x, and 3px at @3x. A 48px measurement from an @3x export is therefore 48 ÷ 3 = 16pt; from an @2x export it is 48 ÷ 2 = 24pt.
Keep iOS layout specifications in points. Xcode and UIKit layout APIs work in points, while the rendering system maps points to physical pixels using the screen scale. Export raster artwork at the required scale, but do not turn every point value into a pixel value in the layout spec. A 1pt divider is 2 physical pixels at @2x and 3 physical pixels at @3x.
Check fractional outcomes before accepting a measured screenshot value. For example, 25px at @2x is 12.5pt. That can be a valid layout position, but a sharp border or icon edge may fail to align to whole physical pixels on the target scale.
Tip: When inspecting a screenshot, confirm whether it was exported at native scale; messaging apps and documentation tools often downsample images before you measure them.
4. Convert web pixels to rem without assumptions
For a manual px to rem converter calculation, use rem = px ÷ root font size. In the common browser default configuration, the root font size is 16px, so 16px equals 1rem, 8px equals 0.5rem, and 24px equals 1.5rem. Verify the actual computed font size on the html element before publishing a token sheet, because a product can set a different root size.
Use rem for web spacing and type values that should follow the root font size. em is different: it resolves against the current element’s font size, so nested components can compound an em value. A 1em gap inside a component with a 20px computed font size is 20px, while 1rem remains tied to the root.
If the same token is 16dp and 16pt, its common web export is 1rem only when the root is 16px. Record this condition in the token documentation instead of presenting 1rem as a universal 16px conversion.
Tip: Inspect the browser’s computed
font-sizeforhtml, not a child text style, before converting a pixel token to rem.
5. Validate integer pixels at every export scale
Check every border, icon edge and repeated spacing value against the raster scales you actually ship. Half-pixel values produce blurry edges when an edge falls between device-pixel boundaries: the renderer anti-aliases coverage across adjacent pixels instead of filling one pixel cleanly. This is most visible on 1px rules, square icon strokes and high-contrast chart lines.
Work backward from the logical token. A 0.5pt iOS divider becomes 1px at @2x but 1.5px at @3x, so it cannot be crisp at both scales. Prefer 1pt if the divider must be consistently sharp; it maps to 2px at @2x and 3px at @3x. On Android, a 0.5dp line maps to 1px at xhdpi but 1.5px at xxhdpi, creating the same trade-off.
For spacing, fractional logical values can be acceptable when the visual rhythm requires them. For hard-edged geometry, select values whose multiplication by each target scale is a whole number, then test on at least one @2x or @3x iOS device and one Android density configuration.
Tip: Do not “fix” a blurry 1px screenshot rule by changing only its opacity; first check whether its position and thickness resolve to whole device pixels.
Reference table
Unit conversion baselines and scales
| Platform or unit | Baseline rule | Example conversion |
|---|---|---|
| Android mdpi | 160dpi; 1dp = 1px | Android baseline density |
| Android hdpi | 240dpi; 1.5px = 1dp | 1.5× density scale |
| Android xhdpi | 320dpi; 2px = 1dp | 2× density scale |
| Android xxhdpi | 480dpi; 3px = 1dp | 3× density scale |
| Android xxxhdpi | 640dpi; 4px = 1dp | 4× density scale |
| iOS @1x | 1px = 1pt | 1× display scale |
| iOS @2x | 2px = 1pt | 2× display scale |
| iOS @3x | 3px = 1pt | 3× display scale |
| Web rem | 16px = 1rem | At 16px root size |
Do it with the free px to rem Converter
Convert pixels to rem, em, pt, dp and sp, with every density export size and a full token scale.
Open the px to rem Converter → — free, no sign-up.
Common mistakes
Copying a screenshot measurement into Android as dp.
Divide the screenshot pixels by its Android density scale first. A 48px xhdpi measurement is 24dp, while 48dp is a different and larger layout value.
Treating every iOS screenshot pixel as a point.
Divide by the capture scale: 2 for @2x and 3 for @3x. Confirm that the image has not been resized after capture.
Assuming 1rem always equals 16px.
1rem equals the computed root font size. Use 16px only when the html root is at the common default or has been explicitly set to 16px.
Using fractional dp or pt for hairlines across all densities.
Check the physical-pixel result at each target scale. A fractional logical thickness can be sharp on one scale and anti-aliased on another.
Frequently asked questions
How do I convert px to dp on Android?
Convert pixels to dp by dividing pixels by the Android density scale, where mdpi is 1, hdpi is 1.5, xhdpi is 2, xxhdpi is 3 and xxxhdpi is 4. For example, 48px at xhdpi equals 24dp. Android defines the baseline as 1dp equal to 1px at 160dpi mdpi.
How do I convert px to pt mobile values for an iPhone?
Convert iPhone pixels to points by dividing by the image’s display scale: 1 at @1x, 2 at @2x or 3 at @3x. A 60px measurement from an @3x image is 20pt. Use points for the iOS layout specification and pixels only for scale-specific raster exports.
Is 1rem always 16px?
No, 1rem equals the computed font size of the root element, not a fixed 16px value. A 16px root makes 1rem equal 16px, which is the common browser default configuration. If html computes to 20px, 1rem equals 20px and 16px equals 0.8rem.
Why does a 1px line look blurry on mobile?
A 1px line looks blurry when its thickness or position lands between physical device pixels and the renderer anti-aliases it across adjacent pixels. Check both the logical size and the target scale: 0.5pt is 1px at @2x but 1.5px at @3x. Use whole physical-pixel alignment for hard-edged rules and icons.
Should Android text use dp or sp?
Android text should use sp because sp follows the user’s font-size preference while dp does not. Use dp for layout dimensions such as padding, component height and icon containers. Test text at enlarged system font settings because a fixed-height component can clip an sp-based label.
Where this leaves you
A reliable conversion starts with the scale attached to the source pixel value. Convert Android captures through the mdpi-based density scale, iOS captures through the @ scale, and web values through the computed root font size. Keep one semantic token, then derive its dp, pt, rem and raster-pixel outputs from that token. This avoids the quiet drift that appears when a 16px screenshot value is copied into three codebases as though it meant the same thing. Your next action is to take one existing spacing token, label its source scale, and calculate all four outputs before adding it to the shared token file.
Design the screens first
Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.
Related
- •Aspect Ratio Calculator — Work out the missing width or height for any ratio, with the common phone and store ratios one click away.
- •Device Size Reference — Screen dimensions, density and safe areas for current handsets — searchable, and exportable as code.
- •iPhone Screen Sizes for Design: 2026 Reference — iPhone screen sizes for design: choose a 393 pt canvas, set @2x and @3x assets, and test s
- •App Development Cost Calculator: Estimate Build Cost — Use an app development cost calculator method to turn screens, rates, design systems and r
- •Gemini 3.1 for Mobile App UI Design: 4 Real Prompts Tested Hands-On (2026) — I tested Gemini 3.1 Pro with 4 real mobile app UI prompts — fitness tracker, food delivery